Re: Sync API for workers

On Tue, Sep 4, 2012 at 4:23 AM, David Bruant <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.  We're not throwing
away async; we're bringing sync back into the game where it's appropriate.

 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

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.

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

-- 
Glenn Maynard