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

[Ian Hickson]

On Thu, 3 Dec 2009, Fumitoshi Ukai (éµ~\飼æ~V~Gæ~U~O) wrote:
>
> I've question about thread to run Web Socket feedback from the protocol.
> 
> If server sends back handshake response and a data frame, and close 
> immediately, fast enough to run JavaScript on browser, how readyState 
> should be?
> 1) When client recognizes handshake response header, it changes readyState
> to OPEN  and queue a task to fire a simple event named "open".
> 2) Then client reads a data frame, and queue a task to fire a MessageEvent.
> 3) Then client recognizes the socket is closed, it changes readyState to
> CLOSED and queue a task to fire a simple event named "close".
> 
> I'm wondering this process should be done on the same thread of the
> JavaScript, or may be on the different thread.

It may be done on a different thread. (It doesn't _have_ to be done on a 
different thread; that would be indistinguishable from a slower network.)


> If it should run on the same thread,  1) would be processed after JavaScript
> code is processed. Thus, readyState is OPEN when it receives "open" event.
> However, if it may run on the different thread, 1)-3) might be processed
> before JavaScript code is processed.  So, readyState might be CLOSED when it
> receives "open" event.
> 
> Which is correct behavior?
> It seems WebKit/Mac does former, and Chromium does latter, so
> LayoutTests/websocket/tests/simple.html would fail with Chromium.

Both are correct. The test is incorrect in that it cannot predict what the 
readyState will be unless it has very strict timing relative to the 
server. (Such tests should exist, of course, but they are more complicated 
to write.)


On Thu, 3 Dec 2009, Alexey Proskuryakov wrote:
> 
> I'd expect it to work in the same way it works for XMLHttpRequest - 
> e.g., in an onreadystate handler of XMLHttpRequest, readyState does not 
> change due to background processing of incoming data.

On Thu, 3 Dec 2009, Alexey Proskuryakov wrote:
> 
> On the other hand, it can't possibly work like XMLHttpRequest - for 
> whatever reason, the Web Sockets spec says that events are posted 
> asynchronously. Maybe I'm not the last an only one to get confused by 
> this difference from XMLHttpRequest events.

I could change the spec to make the readyState attribute changes be 
queued along with the event dispatch, but then we'd have a situation 
whereby the "actual" state of the websocket object might not match the 
state returned by the attribute. Is that preferred?

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