[Bug 25081] Make read operation really async

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

--- Comment #3 from Arun <arun@mozilla.com> ---
(In reply to Anne from comment #2)
> Okay, if throwing is always the correct thing to do (and compatible) we can
> do that but then the check should not be there.
> 
> There's a bunch of scenarios.
> 
> 1. send(closedBlob);


As you mention, this is accounted for in the current scenario: read methods
throw if the Blob is closed; the Blob is set to 0 bytes if CLOSED, and
subsequent operations on it are mostly spec'd to throw.


> 2. send(blob); blob.close();

Close is spec'd not to affect any read currently underway. That is, unless at
the time of a read operation, the blob is neutered, the read will go through
and the bag of bits will be read into the format specified by the read method.
It won't affect a read in progress, but of course it will affect a subsequent
read.


> 3. send(blob); setTimeout(() => blob.close(), 0)


I think the above holds true here too.

> 
> It seems you account for 1, but not 2 or 3. I think the way to account for 1
> would actually be directly in the algorithm itself (potentially a wrapper
> around the read operation if it happens often) and not the asynchronous read
> operation because then you overload that operation with two distinct
> purposes (sync checking of close and async reading).


So actually, I just have a "read operation" which takes a synchronous flag, and
behaves differently if the synchronous flag is set or unset. The check for
neutered blobs occurs before the check for the synch. flag. I am checking
"directly in the algorithm itself." Can you help me out with an example of what
you think would be an improvement?

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Wednesday, 19 March 2014 20:03:06 UTC