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

[Alexey Proskuryakov]

On 09.12.2009, at 4:39, Ian Hickson wrote:

>>> I could change the spec to make the readyState attribute changes be
>>> queued along with the event dispatch,
>>
>> I do not understand why the events are queued, to begin with.
>
> How else would it work? We can't interrupt a running script to run an
> event dispatch, or fire an event in the middle of the HTML parser  
> running,
> or fire an event while a plugin is doing sychronous DOM changes -- we
> always have to wait for the event loop's current running task to have
> finished. That's what queuing a task means.

This is only an issue if WebSocket handling is performed in some other  
thread of execution (and even then, it's not really an issue). But I  
don't think that's the best way to think about it.

Data from network is only processed as an event loop task, so it's  
possible and desirable to dispatch events right away. Both single- 
process and multi-process implementations I know of do so - and even  
if some future implementation wants to run WebSocket code on a  
different thread, they can easily implement synchronous event dispatch  
by posting an event and waiting for it to be processed.

This is no different from how XMLHttpRequest works - browser engines  
do not need to queue tasks for onreadystate events, and do not - those  
are dispatched right away.

>>> but then we'd have a situation whereby the "actual" state of the
>>> websocket object might not match the state returned by the  
>>> attribute.
>>
>> This doesn't sounds like an issue to me. The "actual" state is always
>> out of sync, because client and server have different ideas of actual
>> state. So does an Ethernet controller, OS interrupt handler, low  
>> level
>> OS networking code, etc. The only state that matters client-side is  
>> what
>> JavaScript code sees, and all the intermediaries must (and do) act  
>> as if
>> that were the real thing.
>
> I'm not talking about the state of the network, but about the state  
> of the
> object itself. You would end up in situations where, for instance,  
> sending
> would work fine, even though the state attribute said that you hadn't
> connected yet.
>
> I suppose we could get around that by saying that the attribute _is_  
> the
> state, so even if the object thinks it has a connection, the send()  
> would
> still fail until the first event has fired and the state has  
> changed...
> Would that be acceptable?


I don't understand what this means.

- WBR, Alexey Proskuryakov