Blocking message passing for Workers

[Alan deLespinasse]

I would find it extremely useful to have a function available to a Worker
that would block and wait for a message from another Worker or from the
main thread. For example, instead of:

onmessage = function(event) {
// Do some work
// Save all state for next time
};

I'd like to have something like this:

while (true) {
var data = waitForMessage().data;
// Do some work
}

or:

var subworker = new Worker('subworker.js');
while (true) {
var data = subworker.waitForMessage().data;
// Do some work
}

A timeout would probably be nice to have. I don't have an opinion on
whether having a timeout should be optional or required.

Of course you wouldn't want to do this in the main thread, just as you
wouldn't use a synchronous XMLHttpRequest. But it's fine to have a Worker
loop indefinitely and block while waiting for results from somewhere else.

Is this a possibility?

Is there already some way to do this that I'm not aware of?

Do I need to expand on my reasons for wanting such a thing?

[Glenn Maynard]

Post by Alan deLespinasse
I would find it extremely useful to have a function available to a Worker
that would block and wait for a message from another Worker or from the
onmessage = function(event) {
// Do some work
// Save all state for next time
};
while (true) {
var data = waitForMessage().data;
// Do some work
}
var subworker = new Worker('subworker.js');
while (true) {
var data = subworker.waitForMessage().data;
// Do some work
}

There have probably been other threads since, but here's a starting point:

http://lists.w3.org/Archives/Public/public-webapps/2010OctDec/1075.html

[Alan deLespinasse]

Thanks. Apparently I did a lousy job of searching for previous discussions.

I just found this later, longer thread:

http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/0965.html
http://lists.w3.org/Archives/Public/public-webapps/2012JanMar/0678.html
(same thread, different year, so they're not linked)

Has anything changed since that thread? It seems like the discussion
stalled in early 2012. But I'm glad to find that other people want the same
thing.

My motivation for wanting this is probably a bit different than most. The
contributors to the Web Audio API spec have decided (though it's not
completely specced out yet) that the event handler for a
ScriptProcessorNode should happen synchronously in a Worker, rather than
asynchronously in the UI thread as it has been so far. In the specific case
of an OfflineAudioContext, which does not run in real time, blocking the
thread while waiting for data from another thread would be not only
acceptable, but sometimes desirable. If you return from the event handler
to allow the event loop to run, offline audio rendering will continue
without the needed data, which would result in unacceptable glitches in the
rendered audio.

(Discussion:
https://github.com/WebAudio/web-audio-api/issues/113#issuecomment-50695322)

I could try to convince the Web Audio API folks to add a special feature
just for this scenario, but such a feature would probably have to be ugly,
and it seems like a much better idea to add a more generally useful feature
to Worker communications in general. A waitForMessage function is very
straightforward and seems useful.

On Fri, Aug 8, 2014 at 12:49 PM, Alan deLespinasse <

Post by Alan deLespinasse
I would find it extremely useful to have a function available to a Worker
that would block and wait for a message from another Worker or from the
onmessage = function(event) {
// Do some work
// Save all state for next time
};
while (true) {
var data = waitForMessage().data;
// Do some work
}
var subworker = new Worker('subworker.js');
while (true) {
var data = subworker.waitForMessage().data;
// Do some work
}

http://lists.w3.org/Archives/Public/public-webapps/2010OctDec/1075.html
--
Glenn Maynard

[David Bruant]

Post by Alan deLespinasse
Thanks. Apparently I did a lousy job of searching for previous
discussions.
http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/0965.html
http://lists.w3.org/Archives/Public/public-webapps/2012JanMar/0678.html
(same thread, different year, so they're not linked)
Has anything changed since that thread? It seems like the discussion
stalled in early 2012. But I'm glad to find that other people want the
same thing.

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.

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

David

[1] https://twitter.com/briankardell/status/497843660680351744
[2] https://github.com/lukehoban/ecmascript-asyncawait#example
[3] https://bugzilla.mozilla.org/show_bug.cgi?id=783190#c26

[Brian Kardell]

Post by David Bruant

Post by Alan deLespinasse
Thanks. Apparently I did a lousy job of searching for previous discussions.
http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/0965.html
http://lists.w3.org/Archives/Public/public-webapps/2012JanMar/0678.html
(same thread, different year, so they're not linked)
Has anything changed since that thread? It seems like the discussion

stalled in early 2012. But I'm glad to find that other people want the same
thing.

Post by David Bruant
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.

Post by David Bruant
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?

Post by David Bruant
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).

Post by David Bruant
David
[1] https://twitter.com/briankardell/status/497843660680351744
[2] https://github.com/lukehoban/ecmascript-asyncawait#example
[3] https://bugzilla.mozilla.org/show_bug.cgi?id=783190#c26

[David Bruant]

Post by David Bruant
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.

David

[Brendan Eich]

Post by David Bruant

Post by David Bruant
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? 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
on non-main-thread sync input operations?

/be

[David Bruant]

Post by Brendan Eich

Post by David Bruant

Post by David Bruant
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).

Post by Brendan Eich
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.

Post by Brendan Eich
on non-main-thread sync input operations?

Why haven't workers begun with sync primitives?

David

[Brendan Eich]

Post by David Bruant

Post by Brendan Eich

Post by David Bruant

Post by David Bruant
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.

Post by David Bruant
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.

Post by David Bruant
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

[Domenic Denicola]

One thing that I haven't seen anyone explicitly state on this thread, in response to David's points, is that the semantics are observably and crucially different between

fs.readFileSync("file.txt");
console.log("read it!");

and

await fs.readFile("file.txt");
console.log("read it!");

The former blocks the event loop, whereas the latter lets it continue spinning. Even though in both cases "read it!" will only be logged after the file is completely read from disk, in the former case *nothing* else will happen (on that thread) until the file is finished reading. Whereas in the latter case, other asynchronous processes may finish and run their continuations; timers may fire; network events may trigger reactions; etc. That can modify local state, complicating your program's reasoning process and certainly making porting hard, if nothing else.

Realizing the difference between these is important background to realizing why async + sugar cannot replace synchronous code. (Apologies if this was stating the obvious...)

[David Bruant]

Post by Domenic Denicola
Realizing the difference between these is important background to realizing why async + sugar cannot replace synchronous code. (Apologies if this was stating the obvious...)

Is replacing sync APIs a goal? It sure isn't mine.
My point is that from a purely technical perspective async is better as
it allows better reuse of process/threads. Historically async
programming has been hard to read/write. Things are getting better as
programming languages evolve (ES7) is all I'm saying.

David

[David Bruant]

Post by Brendan Eich

Post by David Bruant

Post by Brendan Eich

Post by David Bruant

Post by David Bruant
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).

Post by Brendan Eich
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).

Post by Brendan Eich
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.

Post by Brendan Eich

Post by David Bruant
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.

Post by Brendan Eich

Post by David Bruant
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

[Brendan Eich]

Post by David Bruant
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).

Sorry I missed this -- do you have a link to the thread?

Post by David Bruant

Post by Brendan Eich
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).

This is a circular argument. We have a choice for workers to do
something different (and in addition, not instead-of).

/be

[David Bruant]

Post by Brendan Eich

Post by David Bruant
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).

Sorry I missed this -- do you have a link to the thread?

I proposed exposing both here
http://lists.w3.org/Archives/Public/public-webapps/2013OctDec/0164.html
Jonas Sicking wasn't sold
http://lists.w3.org/Archives/Public/public-webapps/2013OctDec/0165.html
And I haven't found later replies on this topic.

David

[Brendan Eich]

Post by David Bruant
I proposed exposing both here
http://lists.w3.org/Archives/Public/public-webapps/2013OctDec/0164.html
Jonas Sicking wasn't sold
http://lists.w3.org/Archives/Public/public-webapps/2013OctDec/0165.html

You didn't reply, but we now have a good argument thanks to your point
here, about reusing async-only JS libraries.

Post by David Bruant
And I haven't found later replies on this topic.

Alon replied to Jonas, saying somewhat more gently what I said about
generators/async-functions/whole-program-CPS-conversion being infeasible
for Emscripten:

http://lists.w3.org/Archives/Public/public-webapps/2013OctDec/0175.html

Jonas's desire for parsimony is a good design bias, but we now have a
reason to consider async as well as sync APIs for workers.

However, I'd still want some case analysis. Do we see Emscripten using
IndexedDB to emulate a synchronous filesystem? If we have a sync f/s API
that's closer to Unix/C, perhaps there's no Emscripten-based need.
Cc'ing Alon, assuming Jonas will catch up on the list.

/be

[Jan Varga]

Post by Brendan Eich

Post by David Bruant
I proposed exposing both here
http://lists.w3.org/Archives/Public/public-webapps/2013OctDec/0164.html
Jonas Sicking wasn't sold
http://lists.w3.org/Archives/Public/public-webapps/2013OctDec/0165.html

You didn't reply, but we now have a good argument thanks to your point
here, about reusing async-only JS libraries.

Post by David Bruant
And I haven't found later replies on this topic.

Alon replied to Jonas, saying somewhat more gently what I said about
generators/async-functions/whole-program-CPS-conversion being
http://lists.w3.org/Archives/Public/public-webapps/2013OctDec/0175.html
Jonas's desire for parsimony is a good design bias, but we now have a
reason to consider async as well as sync APIs for workers.
However, I'd still want some case analysis. Do we see Emscripten using
IndexedDB to emulate a synchronous filesystem? If we have a sync f/s
API that's closer to Unix/C, perhaps there's no Emscripten-based need.
Cc'ing Alon, assuming Jonas will catch up on the list.
/be

Sync IndexedDB API has been experimentally implemented as a diploma
thesis project, bug 798875.
The patch is quite old, besides a rebase, we would need to update it to
use PBackground.
Anyway, almost all the mochitests we have for async IDB testing have
been copied and rewritten to test the experimental sync IDB implementation.

If we need something fast, reviving sync IDB implementation would be
probably more efficient than designing a sync file system API,
implementing it and writing tests.
There's also no async file system implementation yet.

Jan

[Glenn Maynard]

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 still seem to be confusing the issue that I explained earlier. There's
nothing wrong with blocking in and of itself, it's doing it in a shared
thread like a UI thread that causes problems.

Workers don't have all the APIs that main-thread JS has today. What's

Post by Brendan Eich
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?

No, the general idea was that most APIs (especially complex ones, like IDB)
would only have async APIs. The block-until-a-message-is-received API
(which is all this thread is about) could then be used to create a sync
interface for any async interface (or any combination of async interfaces,
or for number crunching work in another worker). Nobody said anything
about only having sync APIs.

[Joshua Bell]

Post by Glenn Maynard

Post by David Bruant
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 still seem to be confusing the issue that I explained earlier.
There's nothing wrong with blocking in and of itself, it's doing it in a
shared thread like a UI thread that causes problems.

Post by David Bruant
Workers don't have all the APIs that main-thread JS has today. What's

Post by Brendan Eich
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?

No, the general idea was that most APIs (especially complex ones, like
IDB) would only have async APIs. The block-until-a-message-is-received API
(which is all this thread is about) could then be used to create a sync
interface for any async interface (or any combination of async interfaces,
or for number crunching work in another worker). Nobody said anything
about only having sync APIs.

+1 - There's a parallel discussion over in
https://groups.google.com/a/chromium.org/d/msg/blink-dev/ud14qC8yw30/ddLLwdJz4dgJ
about
such a thing.

I'd be loathe to introduce any worker-only sync variations of a
window-exposed async API (like IDB) until we first expose the blocking
primitives to the platform that let us implement a polyfill (as Darin
suggests) and reason/specify about the sync API (as Jonas suggests).

Post by Glenn Maynard
--
Glenn Maynard

[Glenn Maynard]

Post by David Bruant
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.

Post by David Bruant
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.

[David Bruant]

Post by David Bruant
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.

Post by David Bruant
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.

David

[Jeffrey Walton]

Post by Glenn Maynard

Post by David Bruant
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.

Asynch complicates diagramming and modelling because you need a state
machine instead of a simple ladder diagram.

One of the reasons cited for the heartbleed failure was standards
imposed complexity. Forcing async when sync will suffice surely
complicates some programs.

I also find it easier to audit the latter.

Jeff

[Glenn Maynard]

Post by Glenn Maynard

Post by David Bruant
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 have yet to find a use case for hand-written code that requires
structured programming and cannot be achieved with raw assembly.

Post by Glenn Maynard

Post by David Bruant
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.

That's incorrect. If I want to perform one CPU-intensive task per CPU on a
4-CPU machine, I'm going to have 4 workers whether it's implemented sync or
async. Not all software is a web server.

[David Bruant]

Post by David Bruant

Post by David Bruant
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 have yet to find a use case for hand-written code that requires
structured programming and cannot be achieved with raw assembly.

I guess I misundersood what you meant by "replacement".
What about sync APIs cannot be replaced by async APIs with sugar ?

Post by David Bruant

Post by David Bruant
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.
That's incorrect. If I want to perform one CPU-intensive task per CPU
on a 4-CPU machine, I'm going to have 4 workers whether it's
implemented sync or async. Not all software is a web server.

Web servers are just a caricature of I/O intensive software that forced
the programming culture to move to non-blocking I/O patterns.
I don't understand the mention of CPU-intensive tasks, this use case is
taken care of by the current form of workers, isn't it?

David

[Ian Hickson]

Post by Alan deLespinasse
Thanks. Apparently I did a lousy job of searching for previous discussions.
http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/0965.html
http://lists.w3.org/Archives/Public/public-webapps/2012JanMar/0678.html
(same thread, different year, so they're not linked)
Has anything changed since that thread? It seems like the discussion
stalled in early 2012. But I'm glad to find that other people want the
same thing.

I just noticed this thread. For what it's worth, I don't follow this list
very closely. If you would like to request a new API for Workers, the best
place to do it is the WHATWG mailing list or in the W3C Bug database:

https://www.w3.org/Bugs/Public/enter_bug.cgi?assigned_to=ian%40hixie.ch&blocked=&bug_file_loc=&bug_severity=normal&bug_status=NEW&comment=&component=HTML&contenttypeentry=&contenttypemethod=autodetect&contenttypeselection=text%2Fplain&data=&dependson=&description=&form_name=enter_bug&keywords=&maketemplate=Remember%20values%20as%20bookmarkable%20template&op_sys=other&priority=P3&product=WHATWG&qa_contact=contributor%40whatwg.org&rep_platform=Other&short_desc=&target_milestone=---&version=unspecified

HTH,