On Jul 7, 2008, at 12:57 PM, Mike Ter Louw wrote:
Ian Hickson wrote:
Bringing in Apache as a library is a serious cost compared to
WebSocket whose handshake can be implemented in a dozen lines of
perl.
Careful, there are probably someone out there that will take this as
a challenge to implement Apache in a dozen lines of Perl! :P
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
