[whatwg] Web Sockets
beidson at apple.com
Fri Jul 11 14:08:57 PDT 2008
From the link you provide:
"In some situations, it is more natural to make a blocking call and
have the call return the received value, but this synchronous-style
XHR is currently plagued with the risk of locking up the user's
browser window forever as there is no timeout used in waiting for data
from the server."
The flaw in this argument is that they only see locking up the browser
window "forever" as an evil. This is wrong. It is not okay to lock
up the browser window. Ever.
They go on to explain how if only there were a way to lock up the
browser window *for a little while*, that would be okay:
"1. Add a timeout property to the XMLHttpRequest object that controls
how long an XHR call will wait for the server before aborting the call
and returning null or exception"
This is not a solution. Look at native applications for example. 20
years ago it might have been common - not acceptable, but common - to
block the main thread waiting for a long running i/o operation with
the safety net of a timeout. This is simply not done anymore. Native
applications have turned to either asynchronous i/o, or running
synchronous i/o on a background thread.
"2. Improve handling of UI events during a sync XHR so UI gets
repainted when needed and animated GIFs are run." ... "allows the user
to abort the blocking operation"
This is not user-centric programming and seems pretty unacceptable to
me. The user already said they want to close the browser window, and
they should not have to repeat themselves.
As a coder, I sympathize with those developers who would love the
convenience of programming with synchronous i/o.
As a browser developer and a user of the real web, I know it's a
downright dangerous path to rationalize repeating these past mistakes.
Per my original response, the main objection my coworkers and I have
is with synchronous i/o on the main thread. Now that Hixie has given
us a glimpse at what will become a fleshed out worker thread spec, I
think it's entirely reasonable to allow such operations on such a
As long as protections are in place to make sure "convenience-minded"
developers can't lock up the main thread waiting for a background
operation to complete, of course... ;)
On Jul 11, 2008, at 12:04 PM, Mike Wilson wrote:
> 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:
> 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
>> 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