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

Re: Blocking message passing for Workers

From: Brendan Eich <brendan@secure.meer.net>
Date: Tue, 12 Aug 2014 10:36:28 -0700
Message-ID: <53EA509C.6070400@secure.meer.net>
To: David Bruant <bruant.d@gmail.com>
CC: Brian Kardell <bkardell@gmail.com>, Glenn Maynard <glenn@zewt.org>, adelespinasse@gmail.com, public-webapps WG <public-webapps@w3.org>
David Bruant wrote:
> 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.

It's not much of a reason :-P.

Workers don't have all the APIs that main-thread JS has today. What's 
more, if one chooses to write async-only code for all contexts, then 
there's no problem. Only code written to use a synchronous API would be 
hard to port to the main thread.

If I understand you, you're arguing for everyone manually inverting 
control flow, because that maximizes code re-use. Why not let authors 
maximize or not? Trade-offs exist along multiple dimensions here, and 
code reuse is only one good to consider.

Anyway, the Emscripten (and many other compilers) use-case remains. It's 
not something to hand-wave away.

> 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).

This has nothing to do with the subject.

I mean, sure: there are probably lots of reasons workers are underused 
(see above about missing main-thread APIs), but I doubt that among those 
reasons is the fear of blocking i/o primitives being exposed to workers 
and thereby limiting migration of blocking-worker code -- which would 
have to be written only for that content -- onto the main thread!

Once we have blocking i/o in workers, you may find workers used more in 
practice, certainly by Emscripten'ed code.

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

You're appealing to something here, but I can't tell what. "C, Java and 
all" have not all failed as languages or successful server-side systems 
because of blocking i/o primitives. More the reverse.

Is this Node.js triumphalism? Be careful: notable Node hackers have left 
for Go. Node is not a proof that non-blocking is always and only ever 
the one true way or the best way to do i/o and utilize CPUs, by any means.

/be
Received on Tuesday, 12 August 2014 17:37:01 UTC

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