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

Web workers: synchronously handling events

From: Glenn Maynard <glenn@zewt.org>
Date: Sun, 26 Dec 2010 19:29:34 -0500
Message-ID: <AANLkTin5yHe6=2CNSM7An7A+ObruWxerCxCSmXtESHUi@mail.gmail.com>
To: public-webapps@w3.org
Havn't been able to find this in the spec: is there a way to allow
processing messages synchronously during a number-crunching worker
thread?

A typical use case is a CPU-intensive task that needs to be aborted
due to user action.  For example, it might take 250ms to run a search
on a local database.  This can be triggered on each keystroke,
updating as the user types.  If the user enters another letter into
the text field before the previous search completes, that search may
no longer be needed; the running task should be cancelled so it can
start on the new text.  However, if a "cancel" message is sent to the
thread, it won't receive it until it returns from the work it's doing.

Creating a cancellation message port to run periodically would deal
with this nicely, where a port.dispatch() function would dispatch the
first waiting event that came from that port, if any:

    var cancelling = false;
    cancellation_port.onmessage = function(event) { cancelling = true; }
    while(!finished && !cancelling)
    {
        if(cancellation_port.dispatch())
            continue; /* if a message was received, cancelling may
have been modified */
        /* do work */
    }

Terminating the whole worker thread is the blunt way to do it; that's
no good since it requires starting a new thread for every keystroke,
and there may be significant startup costs (eg. loading search data).

The only way I know to do this currently is to return periodically to
allow events to run, and to resume the work with setTimeout(f, 1).
That's ugly and requires writing algorithms in a specific,
inconvenient way that shouldn't be required in a thread.  Browsers
clamping timeouts to a minimum of 5-10ms also breaks this approach;
hopefully they won't do that from worker threads, but I have a feeling
they will.

I'd hate to be stuck with ugly messaging hacks to achieve this, eg.
having to use other mechanisms not meant for cross-thread messaging,
like a database.  Am I missing something in the API?

-- 
Glenn Maynard
Received on Monday, 27 December 2010 00:30:07 GMT

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