Re: [whatwg/streams] Returning buffers to the underlying source (Issue #1217)

The concrete motivation for this is based on some internal details about how a couple of APIs in Chromium that provide an `UnderlyingSource` are implemented. For example, when an HTTP response body is received the browser process writes it into the producer side of the circular buffer and the renderer reads it out of the consumer side to provide chunks to the `ReadableStream`. This requires both an allocation to create the new `ArrayBuffer` and a copy to populate data into that buffer. BYOB avoids the buffer allocation but doesn't avoid the copy. My proposal here is that if an `ArrayBuffer` could be constructed directly over this shared memory then we could avoid both. The actual performance benefit of doing this is up for debate but it's an interesting API design question so let's just assume for the moment that it might be worthwhile. 😄 

The problem you run into if you try to do this is that the size of that circular buffer is fixed and so unless there's a way for the browser to know when script is done with the buffers it has been given eventually the whole thing will be marked as "in use" and no more progress can be made. The two options I see here are either,

* Solve the problem silently by noticing that we're running out of space, checking to see if script is still holding references to older buffers and forcing copies to be made so that the shared memory is "unlocked".
* Give script a way to explicitly release a buffer back to the `UnderlyingSource` when it is done with it.

An `ArrayBuffer` built on top of browser-owned shared memory like this isn't really a `SharedArrayBuffer` because it isn't being modified by two different threads. Safety comes from the fact that the shared memory can't be reused until the `ArrayBuffer` is released, but that means there needs to be a way for that release to be signaled.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/streams/issues/1217#issuecomment-1035596622

You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/streams/issues/1217/1035596622@github.com>