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" <bruan...@gmail.com
<mailto:bruan...@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
