W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2011

Re: Synchronous postMessage for Workers?

From: Glenn Maynard <glenn@zewt.org>
Date: Thu, 17 Nov 2011 16:04:19 -0500
Message-ID: <CABirCh_qnDPoDt=wtUxO-gS6+OyobO33nn6Y8Cxj_4Mh5SYvgw@mail.gmail.com>
To: Joshua Bell <jsbell@chromium.org>
Cc: public-webapps@w3.org
On Thu, Nov 17, 2011 at 3:47 PM, Joshua Bell <jsbell@chromium.org> wrote:

> ^^^ Nit: That would revert back to being postMessage(), no new API on the
> Worker side.
>

Right, I just copied your example.  (You mean "no new API for sending
messages"--the "get the next event" method would be new API for workers.)

One concern with this overall approach is that any pending message would be
> grabbed, not just one intended as a response.
>

You just create separate MessagePorts to segregate different types of
messages.  messagePort.getMessageIfExists would only retrieve messages on
messagePort.

"Retrieve the first message from a list of message ports", akin to
poll/select, may also be useful, eg. getFirstMessage([port1, port2],
timeout).  I'm not sure if there are use cases for this, but it's worth
mentioning.

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

Right, you can emulate either using the other.  Alternatively, do both:
fire the event synchronously, then return it.

-- 
Glenn Maynard
Received on Thursday, 17 November 2011 21:04:48 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:48 GMT