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