[whatwg] Web Sockets

Blocking I/O on the main thread is ok if it's possible to specify
a timeout for the I/O operation, see:

http://www.openajax.org/runtime/wiki/Synchronous_XHR_Enhancements

and if the UA'a user interface is kept responsive (running animated
GIFs, repainting UI etc) and allows the user to abort the blocking
operation (f ex as a new use of the Stop button), see:

http://www.openajax.org/runtime/wiki/Browser_Unresponsive_Mode_Enhancements

Best regards
Mike Wilson

> -----Original Message-----
> From: whatwg-bounces at lists.whatwg.org 
> [mailto:whatwg-bounces at lists.whatwg.org] On Behalf Of Brady Eidson
> Sent: den 7 juli 2008 22:50
> To: Mike Ter Louw
> Cc: whatwg; Ian Hickson
> Subject: Re: [whatwg] Web Sockets
> 
> On Jul 7, 2008, at 12:57 PM, Mike Ter Louw wrote:
> > Joking aside, should a blocking read/recv call be made available?   
> > In some cases additional lag may be an acceptable compromise for  
> > maintaining the JavaScript call stack until a response arrives.
> 
> My personal take (and the take of most of the people I work with) is  
> that blocking i/o on the main thread should be out of the question.
> 
> No matter what assumptions, guarantees, or compromises are 
> understood  
> in a rationalization for allowing it, we've seen time and time again  
> that they backfire and lead to poor user experiences and bad  
> performance problems.
> 
> Notice I'm explicitly mentioning the main thread - if we get 
> a clear,  
> clean spec for worker threads and we restrict blocking i/o to such  
> worker threads, then sure - go for it!
> 
> ~Brady
> 
>

Received on Friday, 11 July 2008 12:04:11 UTC