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 16:21:32 +0200
Message-ID: <53EA22EC.1080704@gmail.com>
To: Brendan Eich <brendan@secure.meer.net>
CC: Brian Kardell <bkardell@gmail.com>, Glenn Maynard <glenn@zewt.org>, adelespinasse@gmail.com, public-webapps WG <public-webapps@w3.org>
Le 12/08/2014 02:11, Brendan Eich a écrit :
> David Bruant wrote:
>> Le 09/08/2014 16:22, Brian Kardell a écrit :
>>> On Aug 9, 2014 10:16 AM, "David Bruant" <bruant.d@gmail.com 
>>> <mailto:bruant.d@gmail.com>> wrote:
>>> > There is still a case for blocking primitives for projects that 
>>> compile from other languages (C, C++, Python, Java, C#, etc.) to JS 
>>> [3].
>>> >
>>> I'm glad to be switching last night's twitter discussion to a bigger 
>>> medium.  My question here is: what is the proposal (if there is any) 
>>> to balance these and simultaneously ensure that we don't wind up 
>>> limiting ourselves or providing really bad foot guns or two APIs 
>>> depending on whether you're in the main thread or a worker?
>> There isn't such proposal and I don't think that can exist which is 
>> one reason I'm opposed to the introduction of blocking primitives in 
>> workers.
>> I really hope the compile-to-JS use cases will find another way to be 
>> solved.
> There is no other way.
> Why are you arguing from dogma instead of reason?
It won't be possible to run the same code (libraries) in workers and 
main thread. That's a reason, not a dogma.
People already don't use workers that much (because of copy cost 
outweighing computing in most use cases and too many people are still 
unaware of transferables).

> There's no *reason* to say worker overhead is so expensive we should 
> not allow authors to create more workers as needed when some block 
> (temporarily, let's hope
hope? Who was taking about reason? :-p
I don't think hoping for reasonable behaviors from authors works at 
scale, do you? People copy/paste, put copy/pasted code in loop bodies 
without looking into it too much (it's not even funny how often people 
ask me for JS perf advice which ends up being some equivalent of "cache 
this jQuery call in a variable").

With C, Java and all, we already know where adding blocking I/O 
primitives leads to. Admittedly maybe dogma trying to learn from history.

> on non-main-thread sync input operations?
Why haven't workers begun with sync primitives?

Received on Tuesday, 12 August 2014 14:22:06 UTC

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