Sync API for workers

Hi,

A Sync API for workers is being implemented in Firefox [1].
I'd like to come back to the discussions mentionned in comment 4 of the bug.

A summary of points I find important and my comments, questions and concerns

# Discussion 1
## Glenn Maynard [2] Use case exposed:
Ability to cancel long-running synchronous worker task
"Terminating the whole worker thread is the blunt way to do it; that's
no good since it requires starting a new thread for every keystroke, and
there may be significant startup costs (eg. loading search data)."
=> It's a legitimate use case that has no good solution today other than
cutting the task in smaller tasks between which a cancellation message
can be interleaved.


## Tab Atkins [3]
"If we were to fix this, it needs to be done at the language level,
because there are language-level issues to be solved that can't be
hacked around by a specialized solution."
=> I agree a lot with that point. This is a discussion that should be
had on es-discuss since JavaScript is the underlying language.
ECMAScript per se doesn't define a concurrency model and it's not even
on the table for ES.next, but might be in ES.next.next (7?). See [concurr]

## Jonas Sicking [4]
Ideas of providing control (read-only) over pending messages in workers.
(not part of the current Sync API, but interesting nonetheless)



# Discussion 2
## Joshua Bell [5]
"This can be done today using bidirectional postMessage, but of course
this requires the Worker to then be coded in now common asynchronous
JavaScript fashion, with either a tangled mess of callbacks or some sort
of Promises/Futures library, which removes some of the benefits of
introducing sync APIs to Workers in the first place."
=> What are these benefits? Is the cost of the Promises/Future library
so high it
Back to Tab's point of the previous discussion, this is a language
issue, not an API issue. It ought to be solved at the language level


## Rick Waldron [6]
"This is counter to the whole premise of Workers, which should be
independent of their renderer process and certainly not block themselves
while waiting for responses from the renderer (which inherently
describes an async behaviour)."
=> Indeed. Having a blocked worker makes that when you need other tasks
to happen in parallel, you need to spawn new workers which is a waste of
resources, very much like Apache which opens a new thread for each HTTP
connection while some thread are idling (I don't know if it's still the
case, but it used to)


## Glenn Maynard [7]
"I think this is a fundamental missing piece to worker communication.  A
basic reason for having Workers in the first place is so you can write
linear code, instead of having to structure code to be able to return
regularly (often awkward and inconvenient), but currently in order to
receive messages in workers you still have to do that."
=> A basic reason for having workers is to move computation away from
window to a concurrent and parallel computation unit so that the UI is
not blocked by computation. End of story. Nothing to do with writing
linear code. If JavaScript as it is doesn't allow people to write code
as they wish, once again, it's a language issue. Either ask a change in
the language or create a language that looks the way you want and
compiles down to JavaScript.



I wish to add that adding a sync API (even if the sync aspect is
asymetrical as proposed in [1]) breaks the event-loop run-to-completion
model of in-browser-JavaScript which is intended to be formalized at
[concurr]. This model is what prevents web pages from ever freezing from
a deadlock. The proposed API preserves this, but create the threat of
deadlocks for workers.

Besides programmer convenience, few arguments have been advanced to
justify the breakage of the current concurrency model (I don't even
think the breakage has been mentionned at all!). And as said several
times, programmer convenience are more of a language issue than an API
issue for the specific things we're talking about.
Also, I don't think I have seen mentionned use cases of things that are
not possible without a Sync API. Everything presented is already
possible (sometimes at arguably high costs like Glenn Maynard's use case
in discussion [1]).

David

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=783190
[2] http://lists.w3.org/Archives/Public/public-webapps/2010OctDec/1075.html
[3] http://lists.w3.org/Archives/Public/public-webapps/2010OctDec/1082.html
[4] http://lists.w3.org/Archives/Public/public-webapps/2010OctDec/1086.html
[5] http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/0965.html
[6] http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/0966.html
[7] http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/0967.html
[concurr] http://wiki.ecmascript.org/doku.php?id=strawman:concurrency

Received on Saturday, 1 September 2012 16:50:33 UTC