W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2014

Re: Blocking message passing for Workers

From: David Bruant <bruant.d@gmail.com>
Date: Tue, 12 Aug 2014 01:52:39 +0200
Message-ID: <53E95747.4000506@gmail.com>
To: Glenn Maynard <glenn@zewt.org>
CC: Alan deLespinasse <adelespinasse@gmail.com>, public-webapps WG <public-webapps@w3.org>
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 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.

Received on Monday, 11 August 2014 23:53:10 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:14:26 UTC