[whatwg] Web Sockets
mikewse at hotmail.com
Fri Jul 11 12:04:11 PDT 2008
Blocking I/O on the main thread is ok if it's possible to specify
a timeout for the I/O operation, see:
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:
> -----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
> 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
> 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!
More information about the whatwg