[whatwg] [hybi] Races in websocket API?

On Fri, Nov 20, 2009 at 1:10 PM, Greg Wilkins <gregw at mortbay.com> wrote:

> Fumitoshi Ukai (????) wrote:
> > On Thu, Nov 19, 2009 at 1:00 PM, Greg Wilkins <gregw at webtide.com
> >
> >      var ws = new WebSocket("ws://mysite.com
> >     <http://mysite.com>","myprotocol");
> > ...
> >     So if the next line in the script is
> >
> >      ws.onopen=myopenfunc;
> >
> >     there is a race between if the onopen function will
> >     be assigned and if the background connection has been established?
> >
> >
> > I believe open event  is just queued at the moment, and it will be fired
> > later when javascript becomes idle.
>
> Unfortunately this does not appear to be the implementation in chrome
> at least.  If you step through with a debugger, then the close happens
> before my ws.onclose function is assigned, as thus it is never called.
>

Really?
I couldn't reproduce the case.  I put long for loop between new WebSocket
and ws.onopen =, and/or ws.onclose, it will fire onopen and onclose as
expected after chrome showing the page is unresponsive.

 var ws = new WebSocket("ws://localhost:8880/websocket/tests/simple");
debug("wait");
for (var j = 0; j < 50000; j++) {
 for (var i = 0 ; i < 100000; i++) {
  ;
 }
}
debug("wait done");

ws.onopen = function()
{
    debug("Connected.");
};

ws.onmessage = function(messageEvent)
{
    debug("Received: '" + messageEvent.data + "'");
};

ws.onclose = function()
{
    debug("Closed.");
    endTest();
};

-- 
ukai


> Even if it was implemented as you say, I'm wondering if the API should
> be less dependent on the single threaded nature of current javascript
> implementations.
>
> cheers
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20091120/1ba3dcf0/attachment.htm>

Received on Thursday, 19 November 2009 21:08:45 UTC