W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2010

Re: Web workers: synchronously handling events

From: Glenn Maynard <glenn@zewt.org>
Date: Tue, 28 Dec 2010 15:29:29 -0500
Message-ID: <AANLkTim=Y=WwVFnFij7RLe+tB-oxb7eG7fo+dk5xa6bx@mail.gmail.com>
To: "Tab Atkins Jr." <jackalmage@gmail.com>
Cc: public-webapps@w3.org
On Tue, Dec 28, 2010 at 3:06 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
> Yes, by pausing every once in a while with setTimeout and letting the
> event loop spin.
>
> Doing anything else would break javascript's appearance of single-threadedness.

I'm not suggesting that events should run on their own in the middle
of script execution.  I'm suggesting that code should be able to
explicitly, synchronously run the event loop, only for messages from a
specific message port.  I don't think this makes Javascript less
single-threaded-looking; it's analogous to doing a nonblocking read()
from a TTY in Unix, to retrieve the user's next keystroke.

> I agree that it's not particularly nice to write your algorithms like
> this, but it's already familiar to any js dev who uses any algorithm
> with significant running time.  If we were to fix this, it needs to be
> done at the language level, because there are language-level issues to
> be solved that can't be hacked around by a specialized solution.

That's a workaround for doing long-running computations in a UI
thread.  The very reason for using worker threads to do computation in
the first place is so this sort of hack isn't necessary.

-- 
Glenn Maynard
Received on Tuesday, 28 December 2010 20:30:05 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:42 GMT