Re: Blocking message passing for Workers

2014-09-02 Thread Ian Hickson
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

Re: Blocking message passing for Workers

2014-08-12 Thread Glenn Maynard
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

Re: Blocking message passing for Workers

2014-08-12 Thread David Bruant
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

Re: Blocking message passing for Workers

2014-08-12 Thread David Bruant
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

Re: Blocking message passing for Workers

2014-08-12 Thread Brendan Eich
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

RE: Blocking message passing for Workers

2014-08-12 Thread Domenic Denicola
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!);

Re: Blocking message passing for Workers

2014-08-12 Thread David Bruant
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

Re: Blocking message passing for Workers

2014-08-12 Thread David Bruant
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

Re: Blocking message passing for Workers

2014-08-12 Thread Brendan Eich
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

Re: Blocking message passing for Workers

2014-08-12 Thread David Bruant
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

Re: Blocking message passing for Workers

2014-08-12 Thread Brendan Eich
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

Re: Blocking message passing for Workers

2014-08-12 Thread Jan Varga
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

Re: Blocking message passing for Workers

2014-08-12 Thread Glenn Maynard
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

Re: Blocking message passing for Workers

2014-08-12 Thread Joshua Bell
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

Re: Blocking message passing for Workers

2014-08-11 Thread Glenn Maynard
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

Re: Blocking message passing for Workers

2014-08-11 Thread David Bruant
]) 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

Re: Blocking message passing for Workers

2014-08-11 Thread David Bruant
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

Re: Blocking message passing for Workers

2014-08-11 Thread Brendan Eich
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].

Re: Blocking message passing for Workers

2014-08-11 Thread Jeffrey Walton
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

Re: Blocking message passing for Workers

2014-08-09 Thread Alan deLespinasse
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

Re: Blocking message passing for Workers

2014-08-09 Thread David Bruant
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

Re: Blocking message passing for Workers

2014-08-09 Thread Brian Kardell
. 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

Blocking message passing for Workers

2014-08-08 Thread Alan deLespinasse
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

Re: Blocking message passing for Workers

2014-08-08 Thread Glenn Maynard
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 =