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

Re: Synchronous postMessage for Workers?

From: David Levin <levin@chromium.org>
Date: Thu, 17 Nov 2011 14:07:31 -0800
Message-ID: <CACmjMJQQ6of09PbmqCQTow+Y4F_P7CzKJ3Dc8HOCzdX9pJqGnA@mail.gmail.com>
To: Joshua Bell <jsbell@chromium.org>
Cc: public-webapps@w3.org
It seems like this mechanism would deadlock a worker if two workers send
each other a synchronous message.

dave


On Thu, Nov 17, 2011 at 10:37 AM, Joshua Bell <jsbell@chromium.org> wrote:

> Jonas and I were having an offline discussing regarding the synchronous
> Indexed Database API and noting how clean and straightforward it will allow
> Worker scripts to be. One general Worker issue we noted - independent of
> IDB - was that there are cases where Worker scripts may need to fetch data
> from the Window. This can be done today using bidirectional postMessage,
> but of course this requires the Worker to then be coded in now common
> asynchronous JavaScript fashion, with either a tangled mess of callbacks or
> some sort of Promises/Futures library, which removes some of the benefits
> of introducing sync APIs to Workers in the first place.
>
> Wouldn't it be lovely if the Worker script could simply make a synchronous
> call to fetch data from the Window?
>
> GTNW.prototype.end = function () {
>     var result = self.sendMessage({action: "prompt_user", prompt: "How
> about a nice game of chess?"});
>     if (result) { chess_game.begin(); }
> }
>
> The requirement would be that the Window side is asynchronous (of course).
> Continuing the silly example above, the Window script responds to the
> message by fetching some new HTML UI via async XHR, adding it to the DOM,
> and only after user input and validation events is a response sent back to
> the Worker, which proceeds merrily on its way.
>
> I don't have a specific API suggestion in mind. On the Worker side it
> should take the form of a single blocking call taking the data to be passed
> and possibly a timeout, and allowing a return value (on
> timeout return undefined or throw?). On the Window side it could be a new
> event on Worker which delivers a "Promise" type object which the Window
> script can later fulfill (or break). Behavior on multiple event listeners
> would need to be defined (all get the same "Promise", first "fulfill" wins,
> others throw?).
>
>
Received on Thursday, 17 November 2011 22:08:29 GMT

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