On Dec 11, 2007, at 3:02 PM, Oliver Hunt wrote:
It's clear that most people here feel passionately that this is the
wrong thing to do. Perhaps it's best that we table this until
something like workerpools are in the spec.
Worker pools do not resolve the problem, even if you were to force
any synchronous IO to be performed on a worker thread (where by
force i mean attempting synchronous io on the main/ui thread would
throw an exception or similar). The problem is that once you have
multiple threads, and those threads are unable to modify the DOM
(allowing the DOM to be modified from a worker thread would cause
too much havoc -- there is much to much JS out there to allow JS to
become multithreaded), so either you defer the synchronous IO into a
async callback model to tell you when the io has completed -- you
are now using the synchronous api to implement your own async api --
or you have thread constructs such as a rendezvous, which will
eventually end up in the UI thread, thereby reducing any thread
synchronous IO back into a blocking operation.
Worker threads + sync IO available only on the worker thread do have
one advantage over a pure async API: you can batch multiple requests,
handle them using relatively simple code on your worker thread, and
get a single notification on the main thread when all of that is done.
There are many cases where this would be handy. I think the biggest
disadvantage is that it would be more complicated to specify and
implement. And in the end it won't hurt to have both.
(I assume we are all talking about shared-nothing message-passing
threads as in Gears.)
Regards,
Maciej
