[whatwg] Thread to run Web Socket feedback from the protocol ?
Alexey Proskuryakov
ap at webkit.org
Fri Dec 4 10:07:32 PST 2009
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
More information about the whatwg
mailing list