Re: Sync API for workers

On Sat, Sep 1, 2012 at 3:19 PM, Rick Waldron <waldron.rick@gmail.com> wrote:

> I can seriously dispute this, as someone who involved in research and
> development of JavaScript programming for hardware. Processing high volume
> serialport IO is relatively simple with streams and data events. It's just
> a matter of thinking differently about the program.
>

We'll have to professional disagree, then.  I've used both models
extensively, and for some tasks, such as complex algorithms, I find linear
code much easier to write, understand and debug.


On Sat, Sep 1, 2012 at 3:28 PM, Olli Pettay <Olli.Pettay@helsinki.fi> wrote:

> Proposal 3
> Worker:
> postMessage("I want reply to this");
> var events = [];
> while (var m = waitForMessage()) {
>   if (m.data != /* the reply * /) {
>     events.push(m);
>   } else {
>     // do something with message
>   }
> }
> while (events.length()) {
>    dispatchEvent(events.shift());
> }
>

The intent is much simpler:

postMessage("foo");
var response = getMessage();

You're correct that this wouldn't integrate all that well with libraries,
since you may end up receiving an unrelated message.  (Trying to deal with
that is where the bulk of the above comes from--and you probably really
wouldn't want to dispatch unknown events, since that's effectively making
*all* events async.)  That's why I originally proposed this as a method on
MessagePort.  You'd create a dedicated MessagePort to block on, so you
wouldn't collide with (and possibly be confused by, or discard by accident)
unrelated messages.

Of course, that means that while you're waiting for messages on the port,
no other messages are being received, since you aren't in the event loop.
That's just inherent--nothing else that happens during the event loop would
take place either, like async XHR.

I'm not sure how to do the "implicit deadlock prevention" if this is
exposed on MessagePort, though.  (I personally don't find it a problem, as
I said earlier, but I know that a proposal that has that as an option will
have a much better chance of being implemented than one that doesn't.)

- The message must be read in order to reply
>

I'm not quite following here.  You could getMessage at any time, and the
other thread could postMessage at any time--there doesn't have to be a
"hey, send me a message" message in the first place at all.  For example, a
site may have a button that sends a message when clicked.  You don't have
to jump hoops in order to wait for the "query" message to reply to, as it
seems you'd have to with the "reply" proposals.

-- 
Glenn Maynard