Re: Blocking message passing for Workers

On Mon, Aug 11, 2014 at 6:52 PM, David Bruant <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> 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