[Bug 17262] send function should have async interface

https://www.w3.org/Bugs/Public/show_bug.cgi?id=17262

--- Comment #16 from Takashi Toyoshima <toyoshim@chromium.org> 2012-06-04 09:42:40 UTC ---
(In reply to comment #7)
> * Neuter the blob such that any reads from it will fail
> * Use a copy-on-write scheme such that any already existing Blob objects
> maintain
>   their values (this would likely be prohibitively expensive though).
> * Block all writes until any already started reads finish
> * Block all writes until all Blob references to the data go away.

Now, I feel the third one is the complete resolution.
The reason follows.

How can I use a Blob object which might become invalid suddenly?
Read failures inside WebSocket implementation lead connection closed.
It is not acceptable behavior. Thus, the fist idea looks bad to me.

The forth idea is also bad because implicit dependency causes deadlock easily.
Application may hold a read reference to a object when it waits for a write
completion on the same object. Of course, it can be forbidden by API
definition.

The third idea might be good for WebSocket. Because a Blob which is queued into
WebSocket internal buffer will be released sooner or later and it never blocks
any write requests forever. I'm not sure 'any already started reads' includes
'any Blobs queued into WebSocket' But, it must contain. Because read failures
lead the connection closed, and any writers have no chance to know when the
read operations by WebSockets are finished.

Anyway, this discussion must be done in another thread with guys who are
responsible for the FileSystem API and the FileHandle API.

My major interest is the way to realize back pressure at the JavaScript API
level.

-- 
Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Monday, 4 June 2012 09:44:44 UTC