Re: [hybi] Races in websocket API?

[Fumitoshi Ukai (鵜飼文敏) <ukai at chromium.org>]

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

{

    debug("Connected.");

};

ws.>

{

    debug("Received: '" + messageEvent.data + "'");

};

ws.>

{

    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