Re: Blocking message passing for Workers
On Sat, 9 Aug 2014, Alan deLespinasse wrote: 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. I just noticed this thread. For what it's worth, I don't follow this list very closely. If you would like to request a new API for Workers, the best place to do it is the WHATWG mailing list or in the W3C Bug database: https://www.w3.org/Bugs/Public/enter_bug.cgi?assigned_to=ian%40hixie.chblocked=bug_file_loc=bug_severity=normalbug_status=NEWcomment=component=HTMLcontenttypeentry=contenttypemethod=autodetectcontenttypeselection=text%2Fplaindata=dependson=description=form_name=enter_bugkeywords=maketemplate=Remember%20values%20as%20bookmarkable%20templateop_sys=otherpriority=P3product=WHATWGqa_contact=contributor%40whatwg.orgrep_platform=Othershort_desc=target_milestone=---version=unspecified HTH, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: Blocking message passing for Workers
On Mon, Aug 11, 2014 at 6:52 PM, David Bruant bruan...@gmail.com wrote: Le 12/08/2014 00:40, Glenn Maynard a écrit : On Sat, Aug 9, 2014 at 9:12 AM, David Bruant bruan...@gmail.com wrote: 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. Syntax sugar around async is not a replacement for synchronous APIs. I have yet to find a use case for hand-written code that requires sync APIs and cannot be achieved with async programming. I have yet to find a use case for hand-written code that requires structured programming and cannot be achieved with raw assembly. 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). The problem wasn't that synchronous programming is bad, the problem was that synchronous code in the UI thread blocks UI, and the solution to that is asynchronous programming. Saying therefore all synchronous programming is bad is a very deep misunderstanding of the issue. If you block on workers, you'll mechanically need more workers. That's what happened with Apache that was spawning more threads as more HTTP requests were coming because the existing threads were busy waiting for blocking I/O. That's incorrect. If I want to perform one CPU-intensive task per CPU on a 4-CPU machine, I'm going to have 4 workers whether it's implemented sync or async. Not all software is a web server. -- Glenn Maynard
Re: Blocking message passing for Workers
Le 12/08/2014 15:28, Glenn Maynard a écrit : On Mon, Aug 11, 2014 at 6:52 PM, David Bruant bruan...@gmail.com mailto:bruan...@gmail.com wrote: Le 12/08/2014 00:40, Glenn Maynard a écrit : On Sat, Aug 9, 2014 at 9:12 AM, David Bruant bruan...@gmail.com mailto:bruan...@gmail.com wrote: 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. Syntax sugar around async is not a replacement for synchronous APIs. I have yet to find a use case for hand-written code that requires sync APIs and cannot be achieved with async programming. I have yet to find a use case for hand-written code that requires structured programming and cannot be achieved with raw assembly. I guess I misundersood what you meant by replacement. What about sync APIs cannot be replaced by async APIs with sugar ? 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). The problem wasn't that synchronous programming is bad, the problem was that synchronous code in the UI thread blocks UI, and the solution to that is asynchronous programming. Saying therefore all synchronous programming is bad is a very deep misunderstanding of the issue. If you block on workers, you'll mechanically need more workers. That's what happened with Apache that was spawning more threads as more HTTP requests were coming because the existing threads were busy waiting for blocking I/O. That's incorrect. If I want to perform one CPU-intensive task per CPU on a 4-CPU machine, I'm going to have 4 workers whether it's implemented sync or async. Not all software is a web server. Web servers are just a caricature of I/O intensive software that forced the programming culture to move to non-blocking I/O patterns. I don't understand the mention of CPU-intensive tasks, this use case is taken care of by the current form of workers, isn't it? David
Re: Blocking message passing for Workers
Le 12/08/2014 02:11, Brendan Eich a écrit : David Bruant wrote: Le 09/08/2014 16:22, Brian Kardell a écrit : On Aug 9, 2014 10:16 AM, David Bruant bruan...@gmail.com mailto:bruan...@gmail.com wrote: 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? There isn't such proposal and I don't think that can exist which is one reason I'm opposed to the introduction of blocking primitives in workers. I really hope the compile-to-JS use cases will find another way to be solved. There is no other way. Why are you arguing from dogma instead of reason? It won't be possible to run the same code (libraries) in workers and main thread. That's a reason, not a dogma. People already don't use workers that much (because of copy cost outweighing computing in most use cases and too many people are still unaware of transferables). There's no *reason* to say worker overhead is so expensive we should not allow authors to create more workers as needed when some block (temporarily, let's hope hope? Who was taking about reason? :-p I don't think hoping for reasonable behaviors from authors works at scale, do you? People copy/paste, put copy/pasted code in loop bodies without looking into it too much (it's not even funny how often people ask me for JS perf advice which ends up being some equivalent of cache this jQuery call in a variable). With C, Java and all, we already know where adding blocking I/O primitives leads to. Admittedly maybe dogma trying to learn from history. on non-main-thread sync input operations? Why haven't workers begun with sync primitives? David
Re: Blocking message passing for Workers
David Bruant wrote: Le 12/08/2014 02:11, Brendan Eich a écrit : David Bruant wrote: Le 09/08/2014 16:22, Brian Kardell a écrit : On Aug 9, 2014 10:16 AM, David Bruant bruan...@gmail.com mailto:bruan...@gmail.com wrote: 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? There isn't such proposal and I don't think that can exist which is one reason I'm opposed to the introduction of blocking primitives in workers. I really hope the compile-to-JS use cases will find another way to be solved. There is no other way. Why are you arguing from dogma instead of reason? It won't be possible to run the same code (libraries) in workers and main thread. That's a reason, not a dogma. It's not much of a reason :-P. Workers don't have all the APIs that main-thread JS has today. What's more, if one chooses to write async-only code for all contexts, then there's no problem. Only code written to use a synchronous API would be hard to port to the main thread. If I understand you, you're arguing for everyone manually inverting control flow, because that maximizes code re-use. Why not let authors maximize or not? Trade-offs exist along multiple dimensions here, and code reuse is only one good to consider. Anyway, the Emscripten (and many other compilers) use-case remains. It's not something to hand-wave away. People already don't use workers that much (because of copy cost outweighing computing in most use cases and too many people are still unaware of transferables). This has nothing to do with the subject. I mean, sure: there are probably lots of reasons workers are underused (see above about missing main-thread APIs), but I doubt that among those reasons is the fear of blocking i/o primitives being exposed to workers and thereby limiting migration of blocking-worker code -- which would have to be written only for that content -- onto the main thread! Once we have blocking i/o in workers, you may find workers used more in practice, certainly by Emscripten'ed code. With C, Java and all, we already know where adding blocking I/O primitives leads to. Admittedly maybe dogma trying to learn from history. You're appealing to something here, but I can't tell what. C, Java and all have not all failed as languages or successful server-side systems because of blocking i/o primitives. More the reverse. Is this Node.js triumphalism? Be careful: notable Node hackers have left for Go. Node is not a proof that non-blocking is always and only ever the one true way or the best way to do i/o and utilize CPUs, by any means. /be
RE: Blocking message passing for Workers
One thing that I haven't seen anyone explicitly state on this thread, in response to David's points, is that the semantics are observably and crucially different between fs.readFileSync(file.txt); console.log(read it!); and await fs.readFile(file.txt); console.log(read it!); The former blocks the event loop, whereas the latter lets it continue spinning. Even though in both cases read it! will only be logged after the file is completely read from disk, in the former case *nothing* else will happen (on that thread) until the file is finished reading. Whereas in the latter case, other asynchronous processes may finish and run their continuations; timers may fire; network events may trigger reactions; etc. That can modify local state, complicating your program's reasoning process and certainly making porting hard, if nothing else. Realizing the difference between these is important background to realizing why async + sugar cannot replace synchronous code. (Apologies if this was stating the obvious...)
Re: Blocking message passing for Workers
Le 12/08/2014 19:44, Domenic Denicola a écrit : Realizing the difference between these is important background to realizing why async + sugar cannot replace synchronous code. (Apologies if this was stating the obvious...) Is replacing sync APIs a goal? It sure isn't mine. My point is that from a purely technical perspective async is better as it allows better reuse of process/threads. Historically async programming has been hard to read/write. Things are getting better as programming languages evolve (ES7) is all I'm saying. David
Re: Blocking message passing for Workers
Le 12/08/2014 19:36, Brendan Eich a écrit : David Bruant wrote: Le 12/08/2014 02:11, Brendan Eich a écrit : David Bruant wrote: Le 09/08/2014 16:22, Brian Kardell a écrit : On Aug 9, 2014 10:16 AM, David Bruant bruan...@gmail.com mailto:bruan...@gmail.com wrote: 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? There isn't such proposal and I don't think that can exist which is one reason I'm opposed to the introduction of blocking primitives in workers. I really hope the compile-to-JS use cases will find another way to be solved. There is no other way. Why are you arguing from dogma instead of reason? It won't be possible to run the same code (libraries) in workers and main thread. That's a reason, not a dogma. It's not much of a reason :-P. Workers don't have all the APIs that main-thread JS has today. What's more, if one chooses to write async-only code for all contexts, then there's no problem. That's not what I had understood. So both types of APIs (sync and async) will be available to workers for say, IndexedDB? If that's the case, I have no problem with it and we can stop the discussion. What I remembered of the state of the consensus was that given sync APIs were considered needed in workers, they would be added to workers without the async counterpart (since that would duplicate the API surface). If I understand you, you're arguing for everyone manually inverting control flow, because that maximizes code re-use. That's what everyone is already used to doing already (not because of code reuse, but because that's how JS APIs are designed). Why not let authors maximize or not? Trade-offs exist along multiple dimensions here, and code reuse is only one good to consider. Anyway, the Emscripten (and many other compilers) use-case remains. It's not something to hand-wave away. I wasn't. That branch of the discussion was discussing hand-written code. My position on Emscriptenco is I really hope the compile-to-JS use cases will find another way to be solved., to which you answered. People already don't use workers that much (because of copy cost outweighing computing in most use cases and too many people are still unaware of transferables). This has nothing to do with the subject. I mean, sure: there are probably lots of reasons workers are underused (see above about missing main-thread APIs), but I doubt that among those reasons is the fear of blocking i/o primitives being exposed to workers and thereby limiting migration of blocking-worker code -- which would have to be written only for that content -- onto the main thread! Once we have blocking i/o in workers, you may find workers used more in practice, certainly by Emscripten'ed code. Assuming blocking i/o in workers gets widely implemented in browsers of course. With C, Java and all, we already know where adding blocking I/O primitives leads to. Admittedly maybe dogma trying to learn from history. You're appealing to something here, but I can't tell what. C, Java and all have not all failed as languages or successful server-side systems because of blocking i/o primitives. More the reverse. Is this Node.js triumphalism? Be careful: notable Node hackers have left for Go. Node is not a proof that non-blocking is always and only ever the one true way or the best way to do i/o and utilize CPUs, by any means. No Node.js triumphalism, but Node found an interesting balance of being resource efficient while remaining pleasant to read and write is all I'm saying. David
Re: Blocking message passing for Workers
David Bruant wrote: That's not what I had understood. So both types of APIs (sync and async) will be available to workers for say, IndexedDB? If that's the case, I have no problem with it and we can stop the discussion. What I remembered of the state of the consensus was that given sync APIs were considered needed in workers, they would be added to workers without the async counterpart (since that would duplicate the API surface). Sorry I missed this -- do you have a link to the thread? If I understand you, you're arguing for everyone manually inverting control flow, because that maximizes code re-use. That's what everyone is already used to doing already (not because of code reuse, but because that's how JS APIs are designed). This is a circular argument. We have a choice for workers to do something different (and in addition, not instead-of). /be
Re: Blocking message passing for Workers
Le 12/08/2014 20:51, Brendan Eich a écrit : David Bruant wrote: That's not what I had understood. So both types of APIs (sync and async) will be available to workers for say, IndexedDB? If that's the case, I have no problem with it and we can stop the discussion. What I remembered of the state of the consensus was that given sync APIs were considered needed in workers, they would be added to workers without the async counterpart (since that would duplicate the API surface). Sorry I missed this -- do you have a link to the thread? I proposed exposing both here http://lists.w3.org/Archives/Public/public-webapps/2013OctDec/0164.html Jonas Sicking wasn't sold http://lists.w3.org/Archives/Public/public-webapps/2013OctDec/0165.html And I haven't found later replies on this topic. David
Re: Blocking message passing for Workers
David Bruant wrote: I proposed exposing both here http://lists.w3.org/Archives/Public/public-webapps/2013OctDec/0164.html Jonas Sicking wasn't sold http://lists.w3.org/Archives/Public/public-webapps/2013OctDec/0165.html You didn't reply, but we now have a good argument thanks to your point here, about reusing async-only JS libraries. And I haven't found later replies on this topic. Alon replied to Jonas, saying somewhat more gently what I said about generators/async-functions/whole-program-CPS-conversion being infeasible for Emscripten: http://lists.w3.org/Archives/Public/public-webapps/2013OctDec/0175.html Jonas's desire for parsimony is a good design bias, but we now have a reason to consider async as well as sync APIs for workers. However, I'd still want some case analysis. Do we see Emscripten using IndexedDB to emulate a synchronous filesystem? If we have a sync f/s API that's closer to Unix/C, perhaps there's no Emscripten-based need. Cc'ing Alon, assuming Jonas will catch up on the list. /be
Re: Blocking message passing for Workers
On 12/08/14 15:25, Brendan Eich wrote: David Bruant wrote: I proposed exposing both here http://lists.w3.org/Archives/Public/public-webapps/2013OctDec/0164.html Jonas Sicking wasn't sold http://lists.w3.org/Archives/Public/public-webapps/2013OctDec/0165.html You didn't reply, but we now have a good argument thanks to your point here, about reusing async-only JS libraries. And I haven't found later replies on this topic. Alon replied to Jonas, saying somewhat more gently what I said about generators/async-functions/whole-program-CPS-conversion being infeasible for Emscripten: http://lists.w3.org/Archives/Public/public-webapps/2013OctDec/0175.html Jonas's desire for parsimony is a good design bias, but we now have a reason to consider async as well as sync APIs for workers. However, I'd still want some case analysis. Do we see Emscripten using IndexedDB to emulate a synchronous filesystem? If we have a sync f/s API that's closer to Unix/C, perhaps there's no Emscripten-based need. Cc'ing Alon, assuming Jonas will catch up on the list. /be Sync IndexedDB API has been experimentally implemented as a diploma thesis project, bug 798875. The patch is quite old, besides a rebase, we would need to update it to use PBackground. Anyway, almost all the mochitests we have for async IDB testing have been copied and rewritten to test the experimental sync IDB implementation. If we need something fast, reviving sync IDB implementation would be probably more efficient than designing a sync file system API, implementing it and writing tests. There's also no async file system implementation yet. Jan
Re: Blocking message passing for Workers
On Tue, Aug 12, 2014 at 9:21 AM, David Bruant bruan...@gmail.com wrote: With C, Java and all, we already know where adding blocking I/O primitives leads to. Admittedly maybe dogma trying to learn from history. You still seem to be confusing the issue that I explained earlier. There's nothing wrong with blocking in and of itself, it's doing it in a shared thread like a UI thread that causes problems. On Tue, Aug 12, 2014 at 1:38 PM, David Bruant bruan...@gmail.com wrote: Workers don't have all the APIs that main-thread JS has today. What's more, if one chooses to write async-only code for all contexts, then there's no problem. That's not what I had understood. So both types of APIs (sync and async) will be available to workers for say, IndexedDB? No, the general idea was that most APIs (especially complex ones, like IDB) would only have async APIs. The block-until-a-message-is-received API (which is all this thread is about) could then be used to create a sync interface for any async interface (or any combination of async interfaces, or for number crunching work in another worker). Nobody said anything about only having sync APIs. -- Glenn Maynard
Re: Blocking message passing for Workers
On Tue, Aug 12, 2014 at 3:54 PM, Glenn Maynard gl...@zewt.org wrote: On Tue, Aug 12, 2014 at 9:21 AM, David Bruant bruan...@gmail.com wrote: With C, Java and all, we already know where adding blocking I/O primitives leads to. Admittedly maybe dogma trying to learn from history. You still seem to be confusing the issue that I explained earlier. There's nothing wrong with blocking in and of itself, it's doing it in a shared thread like a UI thread that causes problems. On Tue, Aug 12, 2014 at 1:38 PM, David Bruant bruan...@gmail.com wrote: Workers don't have all the APIs that main-thread JS has today. What's more, if one chooses to write async-only code for all contexts, then there's no problem. That's not what I had understood. So both types of APIs (sync and async) will be available to workers for say, IndexedDB? No, the general idea was that most APIs (especially complex ones, like IDB) would only have async APIs. The block-until-a-message-is-received API (which is all this thread is about) could then be used to create a sync interface for any async interface (or any combination of async interfaces, or for number crunching work in another worker). Nobody said anything about only having sync APIs. +1 - There's a parallel discussion over in https://groups.google.com/a/chromium.org/d/msg/blink-dev/ud14qC8yw30/ddLLwdJz4dgJ about such a thing. I'd be loathe to introduce any worker-only sync variations of a window-exposed async API (like IDB) until we first expose the blocking primitives to the platform that let us implement a polyfill (as Darin suggests) and reason/specify about the sync API (as Jonas suggests). -- Glenn Maynard
Re: Blocking message passing for Workers
On Sat, Aug 9, 2014 at 9:12 AM, David Bruant bruan...@gmail.com wrote: 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. Syntax sugar around async is not a replacement for synchronous APIs. 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). The problem wasn't that synchronous programming is bad, the problem was that synchronous code in the UI thread blocks UI, and the solution to that is asynchronous programming. Saying therefore all synchronous programming is bad is a very deep misunderstanding of the issue. -- Glenn Maynard
Re: Blocking message passing for Workers
Le 12/08/2014 00:40, Glenn Maynard a écrit : On Sat, Aug 9, 2014 at 9:12 AM, David Bruant bruan...@gmail.com mailto:bruan...@gmail.com wrote: 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. Syntax sugar around async is not a replacement for synchronous APIs. I have yet to find a use case for hand-written code that requires sync APIs and cannot be achieved with async programming. 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). The problem wasn't that synchronous programming is bad, the problem was that synchronous code in the UI thread blocks UI, and the solution to that is asynchronous programming. Saying therefore all synchronous programming is bad is a very deep misunderstanding of the issue. If you block on workers, you'll mechanically need more workers. That's what happened with Apache that was spawning more threads as more HTTP requests were coming because the existing threads were busy waiting for blocking I/O. David
Re: Blocking message passing for Workers
Le 09/08/2014 16:22, Brian Kardell a écrit : On Aug 9, 2014 10:16 AM, David Bruant bruan...@gmail.com mailto:bruan...@gmail.com wrote: 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? There isn't such proposal and I don't think that can exist which is one reason I'm opposed to the introduction of blocking primitives in workers. I really hope the compile-to-JS use cases will find another way to be solved. David
Re: Blocking message passing for Workers
David Bruant wrote: Le 09/08/2014 16:22, Brian Kardell a écrit : On Aug 9, 2014 10:16 AM, David Bruant bruan...@gmail.com mailto:bruan...@gmail.com wrote: 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? There isn't such proposal and I don't think that can exist which is one reason I'm opposed to the introduction of blocking primitives in workers. I really hope the compile-to-JS use cases will find another way to be solved. There is no other way. Why are you arguing from dogma instead of reason? There's no *reason* to say worker overhead is so expensive we should not allow authors to create more workers as needed when some block (temporarily, let's hope on non-main-thread sync input operations? /be
Re: Blocking message passing for Workers
On Mon, Aug 11, 2014 at 7:52 PM, David Bruant bruan...@gmail.com wrote: Le 12/08/2014 00:40, Glenn Maynard a écrit : On Sat, Aug 9, 2014 at 9:12 AM, David Bruant bruan...@gmail.com wrote: 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. Syntax sugar around async is not a replacement for synchronous APIs. I have yet to find a use case for hand-written code that requires sync APIs and cannot be achieved with async programming. Asynch complicates diagramming and modelling because you need a state machine instead of a simple ladder diagram. One of the reasons cited for the heartbleed failure was standards imposed complexity. Forcing async when sync will suffice surely complicates some programs. I also find it easier to audit the latter. Jeff
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
Blocking message passing for Workers
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
}
A timeout would probably be nice to have. I don't have an opinion on
whether having a timeout should be optional or required.
Of course you wouldn't want to do this in the main thread, just as you
wouldn't use a synchronous XMLHttpRequest. But it's fine to have a Worker
loop indefinitely and block while waiting for results from somewhere else.
Is this a possibility?
Is there already some way to do this that I'm not aware of?
Do I need to expand on my reasons for wanting such a thing?
Re: Blocking message passing for Workers
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
