- From: <bugzilla@jessica.w3.org>
- Date: Tue, 22 Apr 2014 19:08:31 +0000
- To: public-webapps-bugzilla@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25081 --- Comment #23 from Arun <arun@mozilla.com> --- (In reply to Jonas Sicking from comment #22) > What we need here is an algorithm which does something like the following. > Note that this algorithm would be started synchronously from any API which > reads from Blobs. > > > 1. Check the closed flag. If the closed flag is set to true then queue a > task which returns a IO error from this algorithm. This step is always done > asynchronously. > 2. Create a clone of the Blob and call the new clone /clone/ > 2. If the synchronous flag is true, then synchronously read the contents of > /clone/. If an IO error occurs then return an IO error from this algorithm. > If no IO error occurs then return the contents of the Blob. Either way abort > this algorithm. > 3. (The synchronous flag should at this point always be false). Queue a task > to read the contents of /clone/. If reading the contents of /clone/ results > in an IO error, then return an error. Otherwise return the contents of the > blob. > > There's obviously a lot of handwaving here. But the important part is that > we should always synchronously check the closed flag. > > For things like reading from a blob URL there is of course the question > about when we invoke the algorithm. I.e. does setting > > img.src = myblobURL > > synchronously invoke the read algorithm, or does it happen at some later > undefined asynchronous point in time. I think this is exactly the same > question that we've been struggling with when it comes to revoked URLs. > > But all APIs that deal with Blob instances should synchronously invoke the > above algorithm, and would thus synchronously check the closed flag. I think http://dev.w3.org/2006/webapi/FileAPI/#readOperationSection already synchronously checks for the closed flag, but it is certainly lacking the asynchronous error reporting part *and* the cloning part, which Bug 25302 calls for. There are other synchronous determinations that a read operation might do, in addition to checking for closed: snapshot state, for example (http://dev.w3.org/2006/webapi/FileAPI/#file). I think the rule is: as long as there's no IO for a particular algorithm step in the read operation, it's ok to be synchronous. Only IO steps have to be asynchronous. -- You are receiving this mail because: You are the QA Contact for the bug.
Received on Tuesday, 22 April 2014 19:08:33 UTC