Re: Sync API for workers

On Sat, Sep 1, 2012 at 2:32 PM, Glenn Maynard <glenn@zewt.org> wrote:

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


Just wanted to point out that all of the arguments for a wait-for-reply API
in workers also apply to SharedWorkers. It's trickier for SharedWorkers
since they use MessagePorts, and we probably don't want to expose this kind
of API to pages (which also use MessagePorts). But I would strongly prefer
a solution that would be applicable to all kinds of workers, not just
dedicated workers.

FWIW, I find the getMessage(timeout) API (sol'n 3 in the thread) preferable
to adding new "send sync message/reply + related events" to the API.
Perhaps exposing this on both Worker and on MessagePort (with appropriate
errors if getMessage(timeout) is called from page scope with timeout != 0)
would be acceptable? I'm not entirely certain what the semantics of
getMessage() are, though - if you grab a message via getMessage(), does
this imply that normal onmessage event handlers are not run (or perhaps are
run after we re-enter the event loop)?

I am not optimistic that we can do deadlock prevention in the general case
with MessagePorts, for the same reason that it's prohibitively difficult to
reliably garbage collect MessagePorts when they can be passed between
processes.


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