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