Re: [hybi] Races in websocket API?

[Jamie Lokier <[e-mail]>]

John Fallows wrote:
> Greg,
> 
> We raised this as a potential issue during the API design for
> WebSocket (back when it was called TCPConnection), indicating that a
> separate method might be desirable that could be called after the
> WebSocket was constructed and event handlers attached.
> 
> But the decision was made that a single-threaded execution environment
> made a separate method unnecessary, because the execution of the
> onopen handler (for example) could not preempt the execution of the
> following 2 lines of JavaScript code:
> 
> var ws = new WebSocket("ws://kaazing.net/echo");
> ws.onopen = function() { console.log("OPEN"); }
> 
> Therefore, by the time the open event is delivered, the onopen handler
> would have already been attached.

Unfortunately the single-threaded assumption is not correct.

First, it's already been mentioned that when running Javascript under
a debugger under at least one browser, events can be sent and lost
before the second line executes.

Second, all recent browsers have multi-threaded Javascript, under
either Google's WorkerPool API, or WHATWG's Web Workers.

Web Workers have been suggested as a way to use WebSocket effectively,
but this single-threaded assumption might make that combination
difficult to use.  What happens when you create a new WebSocket object
in a Web Worker?  Can that be done safely?

I'm surprised at that, given WHATWG is involved with both WebSocket
and Web Workers.

An obvious solution is a connect() method, similar to XmlHttpRequest's
send() method.

-- Jamie