Re: Synchronous postMessage for Workers?

On Thu, Nov 17, 2011 at 11:28 AM, Glenn Maynard <glenn@zewt.org> wrote:

>
> We discussed a very similar thing about a year ago; I've been meaning to
> bring that up again, so this is probably as good a time as any.
> http://lists.w3.org/Archives/Public/public-webapps/2010OctDec/1075.html
>

Ah, thanks - I should have gone digging.


> The proposal is to allow polling a MessagePort, causing the first queued
> message, if any, to be dispatched (or alternatively, to be returned).  This
> could be easily extended to handle the above, by adding a "blocking
> duration" parameter.
>
> For example, working from Jonas's getMessageIfExists proposal:
>
>
>   self.sendMessage({action: "prompt_user", prompt: "How about a nice game
> of chess?"});
>
^^^ Nit: That would revert back to being postMessage(), no new API on the
Worker side.


>   var msg = messagePort.getMessageIfExists(5.0);
>   if(msg && msg.data) { chess_game.begin(); }
>
> Here, 5.0 means to block for five seconds (with a sentinel like -1 would
> mean "block forever"), and the return value is the MessageEvent, returning
> null if no message is received.
>

One concern with this overall approach is that any pending message would be
grabbed, not just one intended as a response. But we're talking about
workers that are intending to run long-lived functions here anyway so they
must explicitly block/poll to receive any communication. It's a more
complicated model for developers, but the complexity is opt-in. So.... I
like it.

I preferred the "dispatch the first message" approach before, but your
> blocking use case may make the "return the first message" approach better.
>

I agree that "return" makes more sense than "dispatch", since we're
introducing this to support a linear programming style. On the other hand,
you could emulate "return" with "dispatch" via helper functions that swap
in a temporary onmessage handler (a variant on your
getPendingMessageWithoutDelivery example in the older thread)