- From: Alan deLespinasse <adelespinasse@gmail.com>
- Date: Sat, 9 Aug 2014 09:51:56 -0400
- To: Glenn Maynard <glenn@zewt.org>
- Cc: public-webapps WG <public-webapps@w3.org>
- Message-ID: <CAMuhF-LcJRRqAPZd_5uYE8BjHizGeUiiDiWhLw4LXwEqrn6xqg@mail.gmail.com>
Thanks. Apparently I did a lousy job of searching for previous discussions. I just found this later, longer thread: http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/0965.html http://lists.w3.org/Archives/Public/public-webapps/2012JanMar/0678.html (same thread, different year, so they're not linked) Has anything changed since that thread? It seems like the discussion stalled in early 2012. But I'm glad to find that other people want the same thing. My motivation for wanting this is probably a bit different than most. The contributors to the Web Audio API spec have decided (though it's not completely specced out yet) that the event handler for a ScriptProcessorNode should happen synchronously in a Worker, rather than asynchronously in the UI thread as it has been so far. In the specific case of an OfflineAudioContext, which does not run in real time, blocking the thread while waiting for data from another thread would be not only acceptable, but sometimes desirable. If you return from the event handler to allow the event loop to run, offline audio rendering will continue without the needed data, which would result in unacceptable glitches in the rendered audio. (Discussion: https://github.com/WebAudio/web-audio-api/issues/113#issuecomment-50695322) I could try to convince the Web Audio API folks to add a special feature just for this scenario, but such a feature would probably have to be ugly, and it seems like a much better idea to add a more generally useful feature to Worker communications in general. A waitForMessage function is very straightforward and seems useful. On Fri, Aug 8, 2014 at 3:56 PM, Glenn Maynard <glenn@zewt.org> wrote: > On Fri, Aug 8, 2014 at 12:49 PM, Alan deLespinasse < > adelespinasse@gmail.com> wrote: > >> I would find it extremely useful to have a function available to a Worker >> that would block and wait for a message from another Worker or from the >> main thread. For example, instead of: >> >> onmessage = function(event) { >> // Do some work >> // Save all state for next time >> }; >> >> I'd like to have something like this: >> >> while (true) { >> var data = waitForMessage().data; >> // Do some work >> } >> >> or: >> >> var subworker = new Worker('subworker.js'); >> while (true) { >> var data = subworker.waitForMessage().data; >> // Do some work >> } >> > > There have probably been other threads since, but here's a starting point: > > http://lists.w3.org/Archives/Public/public-webapps/2010OctDec/1075.html > > -- > Glenn Maynard > >
Received on Saturday, 9 August 2014 13:52:24 UTC