I think Web Workers is very much "threading for JS done right."
In the sense that (a) actual multi-threading introduces a shitload of complexity (I should know, I did a ton of multi-threaded code both server- and desktop-side back in the days) and (b) most of the time all you want is asynchronous, state-based computing.
The good thing is, in JS we are already well acquainted with the core mechanisms of asynchronous computing: message passing in the form of events and (to a lesser degree) timeouts/intervals.
I don't think DOM tweaking should occur outside the main JS execution thread. It would open a Pandora's box of perf/sync issues, making DOM tweaking even LESS efficient than it is today. So the decision to restrict Web Workers to self-contained, message-based, non-DOM processing seems sound to me.
As for the execution model, I believe all browsers currently implementing Web Workers use a different thread in the same process, but I may be wrong. Still, context-switching or memory-mapping with another process would kill most of the speed benefits of using workers in the first place.
-- Christophe Porteneuve [email protected] -- To view archived discussions from the original JSMentors Mailman list: http://www.mail-archive.com/[email protected]/ To search via a non-Google archive, visit here: http://www.mail-archive.com/[email protected]/ To unsubscribe from this group, send email to [email protected]
