Re: Sync API for workers

David,

Thanks for preparing this summary—I just wanted to note that I still stand behind my original, reality based arguments.

One comment inline..  

On Saturday, September 1, 2012 at 12:49 PM, David Bruant wrote:

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

The original post actually describes an async API—putting the word "sync" in the middle of a method or event name doesn't make it "sync".

As the proposed API developed, it still retains the "event handler"-esque design (https://bugzilla.mozilla.org/show_bug.cgi?id=783190#c12). All of the terminology being used is "async":  
- event  
- callback
- "onfoo"

Even Olli's proposal example is async. https://bugzilla.mozilla.org/show_bug.cgi?id=783190#c9 (setTimeout)

If the argument is "callback hell", save it—because if that's the problem with your program, then your doing it wrong (see: node.js ecosystem).


If this API introduces any renderer process blocking, the result will be catastrophic in the hands of inexperienced web developers.


Rick
  
>  
> 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
>  
>