Re: Synchronous postMessage for Workers?

On Thu, Nov 17, 2011 at 1:37 PM, 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.


Workers are suited quite well to Promises/Futures apis. Sync apis are sore
thumb in GlobalWorkerScope's world.


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

This is counter to the whole premise of Workers, which should be
independent of their renderer process and certainly not block themselves
while waiting for responses from the renderer (which inherently describes
an async behaviour).



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

Rick