[whatwg] Thread to run Web Socket feedback from the protocol ?

[Ian Hickson]

On Wed, 9 Dec 2009, Alexey Proskuryakov wrote:
> On 09.12.2009, at 10:07, Ian Hickson wrote:
> > > > 
> > > > I'm absolutely fine with changing WebSocket to change readyState 
> > > > as part of the same task that dispatches the event
> > > 
> > > Yes, that is what I think the spec should say.
> > 
> > Done.
> 
> As discussed on IRC, this leaves us with a race condition between 
> close() and queued messages. The spec says that once close() is invoked, 
> incoming data should be dropped, but queued tasks to dispatch message 
> event will still be coming.
> 
> This race condition can of course be fixed without much difficulty.

I believe it has been fixed, as per my last e-mail.


> It may be more difficult to similarly rearrange XHR specs.

I'm happy to work with Anne to address this as necessary.


> I find it unfortunate that where the spec says "queue a task", most (or 
> all) implementations will perform those actions immediately. This may be 
> indistinguishable from JavaScript client code, but it will be a source 
> of confusion for developers.

I disagree with your interpretation. Wherever the spec says "queue a 
task", this can be interpreted as meaning a message posted by a network 
thread to the main UI event loop, for UAs where this makes sense. However, 
there are many other UA implementation strategies where explicitly saying 
this would be even further from the actual implementation. I think it is 
inadvisable for specs to be defining things that are not black-box 
testable.

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