Re: ISSUE-173 (ericu): terminal FileWriter progress events should be queued [File API: Writer]

On Fri, Dec 10, 2010 at 3:30 PM, Eric Uhrhane <ericu@google.com> wrote:
> On Fri, Dec 10, 2010 at 3:17 PM, James Robinson <jamesr@google.com> wrote:
>> On Fri, Dec 10, 2010 at 2:04 PM, Eric Uhrhane <ericu@google.com> wrote:
>>>
>>> On Fri, Dec 10, 2010 at 2:39 AM, Anne van Kesteren <annevk@opera.com>
>>> wrote:
>>> > On Fri, 10 Dec 2010 03:24:38 +0100, Web Applications Working Group Issue
>>> > Tracker <sysbot+tracker@w3.org> wrote:
>>> >>
>>> >> ISSUE-173 (ericu): terminal FileWriter progress events should be queued
>>> >> [File API: Writer]
>>> >>
>>> >> http://www.w3.org/2008/webapps/track/issues/173
>>> >>
>>> >> Raised by: Eric Uhrhane
>>> >> On product: File API: Writer
>>> >>
>>> >> When a FileWriter successfully completes a write, currently it:
>>> >> * dispatches a write event
>>> >> * sets readyState to DONE
>>> >> * dispatches a writeend event
>>> >>
>>> >> If you want to start a new write, you can't do it in onwrite, since
>>> >> readyState is still WRITING.  Those events should be queued for
>>> >> asynchronous
>>> >> delivery, so that readyState is DONE by the time they get handled.  If
>>> >> you
>>> >> set up a new write in onwrite, you'll still run the risk of getting
>>> >> confused
>>> >> by the subsequent writeend from the previous write, but that's
>>> >> detectable.
>>> >>
>>> >> I'll have to look and see what other events should be marked as queued.
>>> >
>>> > Why not queue a task that changes readyState and then dispatches write
>>> > followed by writeend, "synchronously" from the task. That is how a
>>> > number of
>>> > things work in XMLHttpRequest.
>>>
>>> That would work too.  Any reason that you don't want to set readyState
>>> before queueing the task?  This is already happening asynchronously,
>>> in response to the write finishing--the important thing is just to
>>> make sure the events are queued, and readyState is updated, before the
>>> first handler runs.
>>
>> I'm not familiar with this particular API, but in general I think it's
>> important that state variables be set at the same time that the relevant
>> event fires.  In other words, code that polls readyState or similar
>> attributes should not be able to observe any change before the related event
>> is fired.
>
> Yeah, that makes sense [+thanks to Jonas for pointing this out
> off-list].  I'll link the readyState change with onwrite in the
> success case and onerror in the failure case, then have onwriteend
> come after.

Oops, didn't mean to reply off-list. For posterity here is what I said:

One of the use cases for readystate is to be able to tell if an event
has fired yet or not. If you set it and then schedule a task to fire
the next event then there is essentially a race condition where
there's a small amount of time between the readystate changes and the
event fires.

/ Jonas

Received on Saturday, 11 December 2010 01:23:11 UTC