W3C home > Mailing lists > Public > whatwg@whatwg.org > December 2009

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

From: Alexey Proskuryakov <ap@webkit.org>
Date: Fri, 04 Dec 2009 10:07:32 -0800
Message-ID: <3E06B198-38B2-4BDA-9012-F45995EDDDE9@webkit.org>

On 03.12.2009, at 18:07, 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.  
Synchronous dispatch seems more useful to authors, as it gives more  
guarantees about connection state when handling the event.  
Implementations have always dealt with the necessary book-keeping to  
present asynchronous networking events in a synchronous manner, and I  
don't think think it's been a problem.

An implementation that keeps parts of WebSocket logic in a different  
thread or process will need to queue readyState event changes as you  
describe, but that will be an implementation detail.

> 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.

- WBR, Alexey Proskuryakov
Received on Friday, 4 December 2009 10:07:32 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:19 UTC