Re: Sync API for workers

On Tue, Sep 4, 2012 at 10:32 AM, David Bruant <bruant.d@gmail.com> wrote:

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

(Understanding asynchronous programming isn't really the issue.  I'm sure
everyone in this discussion has an intuitive grasp of that.)

Those are attempts at making asynchronous code easier to write; they're not
substitutes for synchronous code.  They still result in code with less
understandable, well-scoped state.

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

Workers broke away from requiring the "do a bit of work then keep returning
to the event loop" model of the UI thread from the start.  This is no
different than the APIs we already have.  To take an earlier example:

var worker = createDictionaryWorker();
worker.postMessage("elephant");
var definition = getMessage(worker); // wait for the answer

This is no different than a sync XHR or IndexedDB call to do the same thing:

var xhr = new XMLHttpRequest();
xhr.open("GET", "/dictionary?elephant", false); // sync
xhr.send();
var definition = xhr.responseText;

It simply allows workers, not just native code, to implement these APIs.
That's a natural step.

-- 
Glenn Maynard