W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2014

Re: Blocking message passing for Workers

From: Alan deLespinasse <adelespinasse@gmail.com>
Date: Sat, 9 Aug 2014 09:51:56 -0400
Message-ID: <CAMuhF-LcJRRqAPZd_5uYE8BjHizGeUiiDiWhLw4LXwEqrn6xqg@mail.gmail.com>
To: Glenn Maynard <glenn@zewt.org>
Cc: public-webapps WG <public-webapps@w3.org>
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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:14:26 UTC