Re: Sync API for workers

Le 04/09/2012 17:03, Glenn Maynard a écrit :
> On Tue, Sep 4, 2012 at 4:23 AM, David Bruant <bruant.d@gmail.com 
> <mailto:bruant.d@gmail.com>> wrote:
>
>     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.
>
>
> It seems like you're thinking of asynchronous code as fundamentally 
> better than synchronous code.  It's not; it has a set of 
> advantages--ones that the Web needs badly for the UI thread, in order 
> for scripts and the browser to coexist.  It also has a set of serious 
> disadvantages.
Cognitive load is the only one mentioned so far. It is a serious issue 
since for the foreseeable future, only human beings will be writing 
code. However, as said, there are solutions to reduce this load.
I wish to share an experience.
Back in April, I gave a JavaScript/jQuery training to people who knew 
programming, but didn't know JavaScript. I made the decision to teach 
promises right away (jQuery has them built-in, so that's easy). It seems 
that it helped a lot understanding async programming.
The cognitive load has its solutions.

> We're not throwing away async; we're bringing sync back into the game 
> where it's appropriate.
True. I was exagerating a bit here :-)

>
>     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).
>
>
> You're not talking about this particular API here, you're talking 
> about every sync API in workers.  Having sync APIs in workers and 
> performing blocking tasks in workers isn't something new.
>
>         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?
>
>
> The very first example in the spec is doing work synchronously. 
> http://www.whatwg.org/specs/web-apps/current-work/#a-background-number-crunching-worker
This is a very interesting example and I realize that I have used 
"blocking" and "sync" interchangeably by mistake. I'm against blocking, 
but not sync.
What I'm fundamentally (to answer what you said above) against is the 
idea of blocking a computation unit (like a worker) that does nothing 
but idly waits (for IO or a message for instance). It seems that 
proposals so far make the worker wait for a message and do nothing 
meanwhile and that's a pure waste of resources. A worker has been paid 
for (memory, init time...) and it's waiting while it could be doing 
other things.
The current JS event loop run-to-completion model prevents that waste by 
design.

>
>     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)
>
>
> (The synchronous part is bad for the UI thread, but not a problem in 
> workers, so this isn't a very good argument, at least as summarized here.)
>
>     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),
>
>
> I believe that was his point--it's very hard to programmatically 
> convert synchronous code to asynchronous code.
True, but I mean, we could have read intentions or blog posts of people 
saying "it's way too hard"

>
>     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.
>
>
> I don't want to use a heavily layered environment that compiles to 
> JavaScript in order to write linear code.
I didn't recommend that in the part you're answering to. I was still 
talking about Emscripten and Mandreel and such.
If I had a recommendation, it'd be to use promises.

> I want the Web platform to be robust on its own, without complicated 
> systems piled up on top of it.  Expecting that to be a solution is 
> just throwing in the hat and giving up.  It's the "you don't need a 
> native API for that, just use a library" argument notched up several 
> orders of magnitude.
Eventually good library ideas get into standards. See querySelectorAll 
or DOM4's .remove.
ECMAScript has a strawman to standardize promises. It won't make it to 
ES6, but I have high hopes it will make it eventually.

David