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

Reply via email to