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

Re: Blocking message passing for Workers

On Tue, Aug 12, 2014 at 3:54 PM, Glenn Maynard wrote: > On Tue, Aug 12, 2014 at 9:21 AM, David Bruant 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

Re: Blocking message passing for Workers

On Tue, Aug 12, 2014 at 9:21 AM, David Bruant 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 block

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

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 he

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

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 we

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" > wrote: > There is still a case for blocking primit

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

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 i

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" > wrote: > There is still a case for blocking primitives for projects that compile from other la

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" > wrote: > There is still a case for blocking primitives for projects that compile from other languages (C, C++, Pyth

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 > wrote: Le 12/08/2014 00:40, Glenn Maynard a écrit : On Sat, Aug 9, 2014 at 9:12 AM, David Bruant mailto:bruan...@gmail.com>> wrote: This topic is on people mi

Re: Blocking message passing for Workers

On Mon, Aug 11, 2014 at 6:52 PM, David Bruant wrote: > Le 12/08/2014 00:40, Glenn Maynard a écrit : > > On Sat, Aug 9, 2014 at 9:12 AM, 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 keywor

Re: Blocking message passing for Workers

On Mon, Aug 11, 2014 at 7:52 PM, David Bruant wrote: > Le 12/08/2014 00:40, Glenn Maynard a écrit : > > On Sat, Aug 9, 2014 at 9:12 AM, 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

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" > 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 t

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" > 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 n

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 > 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

Re: Blocking message passing for Workers

On Sat, Aug 9, 2014 at 9:12 AM, 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 f

Re: Blocking message passing for Workers

On Aug 9, 2014 10:16 AM, "David Bruant" 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/096

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/2012Ja

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: Blocking message passing for Workers

On Fri, Aug 8, 2014 at 12:49 PM, Alan deLespinasse 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