- From: Glenn Maynard <glenn@zewt.org>
- Date: Sun, 26 Dec 2010 19:29:34 -0500
- 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 UTC