[whatwg] [hybi] Races in websocket API?
Fumitoshi Ukai (鵜飼文敏)
ukai at chromium.org
Thu Nov 19 21:08:45 PST 2009
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>
More information about the whatwg
mailing list