Re: Blocking message passing for Workers
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 gl...@zewt.org wrote:
On Fri, Aug 8, 2014 at 12:49 PM, Alan deLespinasse
adelespina...@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
Re: Blocking message passing for Workers
Le 09/08/2014 15:51, Alan deLespinasse a écrit : 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. This topic is on people minds [1]. My understanding of where we're at is that ECMAScript 7 will bring syntax (async/await keywords [2]) that looks like sync syntax, but acts asynchronously. This should eliminate the need for web devs for blocking message passing primitives for workers. There is still a case for blocking primitives for projects that compile from other languages (C, C++, Python, Java, C#, etc.) to JS [3]. I personally hope it won't happen as it would be a step backwards. Blocking communication (cross-thread/process/computer) was a mistake. We need a culture shift. The browser and Node.js are a step in the right direction (they did not initiate it, but helped popularize it). David [1] https://twitter.com/briankardell/status/497843660680351744 [2] https://github.com/lukehoban/ecmascript-asyncawait#example [3] https://bugzilla.mozilla.org/show_bug.cgi?id=783190#c26
Re: Blocking message passing for Workers
On Aug 9, 2014 10:16 AM, David Bruant bruan...@gmail.com wrote: Le 09/08/2014 15:51, Alan deLespinasse a écrit : 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. This topic is on people minds [1]. My understanding of where we're at is that ECMAScript 7 will bring syntax (async/await keywords [2]) that looks like sync syntax, but acts asynchronously. This should eliminate the need for web devs for blocking message passing primitives for workers. There is still a case for blocking primitives for projects that compile from other languages (C, C++, Python, Java, C#, etc.) to JS [3]. I'm glad to be switching last night's twitter discussion to a bigger medium. My question here is: what is the proposal (if there is any) to balance these and simultaneously ensure that we don't wind up limiting ourselves or providing really bad foot guns or two APIs depending on whether you're in the main thread or a worker? I personally hope it won't happen as it would be a step backwards. Blocking communication (cross-thread/process/computer) was a mistake. We need a culture shift. The browser and Node.js are a step in the right direction (they did not initiate it, but helped popularize it). David [1] https://twitter.com/briankardell/status/497843660680351744 [2] https://github.com/lukehoban/ecmascript-asyncawait#example [3] https://bugzilla.mozilla.org/show_bug.cgi?id=783190#c26
Re: User Intentions Explainer (was: List of Intentions)
[Cross-posting the comments below per Janina's thoughtful request.] I concur with Janina's insightful remark [at the Indie-UI teleconference on Thursday] that the explainer could evolve into a (potentially cross-group) requirements document. This raises several issues. 1. Harmonization of terminology. We're already seeing differences between the terminology used by WEB Apps in connection with editing and our own terms for similar concepts, e.g., abstract events and intentions. Naming conventions for events aren't harmonized either. 2. Whether there should ultimately be one spec or several, and where the division should lie, is obviously up for discussion. Given the progress we've made to date, it makes good sense that support for interactive editing could reside in its own spec, with its own development schedule. This, after all, is work that we anticipated in Indie-UI but postponed. 3. If there are two or more specs to be produced in this area, we should provide appropriate cross-references (perhaps a non-normative reference in each spec to the requirements would be sufficient), so that user agent and Web application implementors alike can readily appreciate the relationships between the technologies described in the respective documents. My main concern at this point is that the designs be consistent and that terminology be unified wherever possible.
