Re: [xhr] events for async requests (was: Re: [whatwg] Thread to run Web Socket feedback from the protocol ?)

On Wed, 16 Dec 2009, Anne van Kesteren wrote:
> (Moving this thread over to the WebApps WG.)
> 
> On Sat, 05 Dec 2009 00:06:35 +0100, Alexey Proskuryakov <ap@webkit.org> wrote:
> > On 04.12.2009, at 14:30, Jonas Sicking wrote:
> > > However for the events that are fired as a result of network activity,
> > > I see no reason to fire these events asynchronously from that code.
> > 
> > Sounds like we're in complete agreement here. I've missed the change from
> > sync to async dispatch when it was made in XHR specs (both v1 and v2), and I
> > think that it should be reverted.
> 
> That sounds right. I initially misunderstood the way the task queue would work
> together with XMLHttpRequest. It seemed sort of natural that events for
> asynchronous requests would be queued as tasks, but I see that if the network
> event itself is queued we can remove that.
> 
> So to be clear, under step seven of the send() method in
> 
>   http://dev.w3.org/2006/webapi/XMLHttpRequest/#the-send-method
> 
> nothing would change. We still want to queue tasks for things that happen on
> the network so that the "same-origin request event rules" run asynchronously
> as it were. However, everything that follows from that should no longer queue
> a task, right? I.e. once the initial task queued as result of network activity
> is run everything should be done synchronously.

Sounds right.


> Later on in the thread on the WHATWG you and Ian allude to difficulties with
> the XMLHttpRequest specification with respect to race conditions if we
> rearrange this. Could you perhaps give an example as I am not sure what would
> be an issue if I make the above changes.

The race condition could occur under the following circumstances:

 * A setTimeout task is queued.
 * The setTimeout task starts running, but it takes several seconds.
   While it is running:
 * A task is queued under step 7, because all the HTTP headers have been 
   received.
 * Another task is queued under step 7, because the first byte of the 
   response entity body has been received.
 * The setTimeout task finishes.
 * The first "same-origin request event rules" task runs. The event is 
   fired. The event calls abort(). The relevant algorithm runs.
 * The first task finishes.
 * The second "same-origin request event rules" task runs. The 
   object's state is updated and the event is fired, even though the 
   object has already had abort() called. This is the race condition.


On another note, while reading the spec I noticed that no task is queued 
to updated responseText. Does that mean that if I check it continually in 
a tight loop within a task, I can see it change?

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Wednesday, 16 December 2009 17:37:47 UTC