W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2012

Re: Sync API for workers

From: David Bruant <bruant.d@gmail.com>
Date: Tue, 04 Sep 2012 11:23:35 +0200
Message-ID: <5045C897.4030305@gmail.com>
To: Jonas Sicking <jonas@sicking.cc>
CC: "public-webapps@w3.org" <public-webapps@w3.org>

Before anything else, thanks for this detailed and quite complete 

Le 03/09/2012 23:32, Jonas Sicking a écrit :
> The other thing that I wanted to talk about is use cases. It has been
> claimed in this thread that synchronous message passing isn't needed
> and that people can just write code using async patterns. While this
> is absolutely true, I would absolutely say that writing asynchronous
> code is dramatically more complicated than writing synchronous code.
I acknowledge that writing async code may be hard for some with 
The solution I have found personally to this issue is using promises 
which makes async code look sync (+some noise due to JS-the-language). 
Others think promises is a good solution [1]
Dave Herman has created task.js [2] to solve the same problem 
differently (promises+generators).
Some have created compile-to-JS languages (like Roy as I said in a 
previous message) to solve the problem in yet another way.
Others find other solutions.

All these solutions have in common that they reduce the complexity of 
writing/reading async code while keeping the benefits of it against a 
small layer of code.

The proposed solution here throws away all benefits of async code to 
reduce the complexity of writing async code by... writing sync code.

I wish we'd explore more solutions to make async more workable rather 
than throwing away async.
The problem with blocking workers is that it may create a culture of 
creating always more and more blocking workers (like Apache creates more 
and more threads to handle more blocking connections).
I understand the benefit that may come with a sync API, but we all know 
that APIs aren't used the way they're primarily intended and sometimes 
with very bad consequences. I'm afraid the bad consequences of a sync 
API misuse haven't been explored. Maybe soon you'll have people filing 
bugs telling "poor Firefox memory usage when using a lot of workers".

> This is one of the big reasons that we have workers at all.
I had never heard this argument before the topic of sync messaging API 
for workers. Where does it come from?
When I read the worker API, I see a way to create a new computation unit 
and to send messages back and forth, nothing about writing sync code.
Regardless of goal, do people actually write more sync code with workers?
Taras Glek seems to think that the local storage API (which is sync) is 
not a good fit for workers [3]:
"We could expose this API to workers, but then we run into an ethical 
question of bringing crappy APIs to new environments." (the article 
mentions that the localStorage API is synchronous as part of the 
"crappy" aspect of it)

> There is also another use-case which has been brought up. As the web
> platform is becoming more powerful, people have started converting
> code written for other platforms to javascript+html.
By "html", here, do you mean something else than <canvas>?
Is there something that compiles any Windows/Mac/Linus UI framework into 

> For example the
> emscipten[1] and mandreel[2] allow recompiling C++ code to javascript
> which is then run in a web browser.
I've been following loosely this topic and all examples I've seen were 
either about pure computation (like turning a C GZIP library in JS) or 
graphics stuffs (using canvas, hence my above question).

> Many times such code relies on APIs or libraries which contain blocking calls.
Do you have an example of that? I haven't seen one so far, but that's an 
interesting point.
Specifically, I can't recall having seen any C/C++->JS example that were 
doing IO (maybe files, but not network),
Last I heard, Emscripten compiles to JS from LLVM bytecode. I'm not sure 
they rely on any library containing blocking calls.
But as I said, I have been following that loosely.

> Technically it might
> be possible to automatically rewrite such code to use asynchronous
> coding patterns, but so far I don't think anyone has managed to do
> that.
Naively, I would say, that once we've paid the price to compile code 
from one language to another, you're not that far off from compiling to 
a given coding pattern. Especially compiling from LLVM bytecode.
Regardless, has anyone tried at all? Has anyone tried to compile to 
JS+Promises or JS+task.js?
All of the compile-to-the-web movement started recently. Only now do we 
start seeing what it can do. it's just the beginning.
Also, I wish the demand came from the people who do work on Emscripten 
or Mandreel, that they came to standards mailing-list saying "it took us 
a billion hours to compile I/O to JS correctly, we tried promises, 
task.js and it didn't help. It would have taken 10 seconds if we had a 
sync API". But I can't recall having read such a message yet. 
Compile-to-the-web is a complicated field and I wish we didn't try to 
guess for them what they need before they ask.


[1] http://jeditoolkit.com/2012/04/26/code-logic-not-mechanics.html#post
[2] http://taskjs.org/
[3] (see before-last comment) 
Received on Tuesday, 4 September 2012 09:24:10 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:13:38 UTC