Re: Blocking message passing for Workers

Le 12/08/2014 19:36, Brendan Eich a écrit :
> 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.
That's not what I had understood. So both types of APIs (sync and async) 
will be available to workers for say, IndexedDB?
If that's the case, I have no problem with it and we can stop the 
discussion.
What I remembered of the state of the consensus was that given sync APIs 
were considered needed in workers, they would be added to workers 
without the async counterpart (since that would duplicate the API surface).

> If I understand you, you're arguing for everyone manually inverting 
> control flow, because that maximizes code re-use.
That's what everyone is already used to doing already (not because of 
code reuse, but because that's how JS APIs are designed).

> 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.
I wasn't. That branch of the discussion was discussing hand-written code.
My position on Emscripten&co is "I really hope the compile-to-JS use 
cases will find another way to be solved.", to which you answered.

>> 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.
Assuming blocking i/o in workers gets widely implemented in browsers of 
course.

>> 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.
No Node.js triumphalism, but Node found an interesting balance of being 
resource efficient while remaining pleasant to read and write is all I'm 
saying.

David

Received on Tuesday, 12 August 2014 18:39:27 UTC