W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2012

Re: Synchronous postMessage for Workers?

From: Ian Hickson <ian@hixie.ch>
Date: Mon, 13 Feb 2012 19:44:50 +0000 (UTC)
To: Joshua Bell <jsbell@chromium.org>, Jonas Sicking <jonas@sicking.cc>
cc: public-webapps@w3.org, David Levin <levin@chromium.org>
Message-ID: <Pine.LNX.4.64.1202131912450.11170@ps20323.dreamhostps.com>
On Thu, 17 Nov 2011, Joshua Bell wrote:
>
> Wouldn't it be lovely if the Worker script could simply make a 
> synchronous call to fetch data from the Window?

It wouldn't be so much a synchronous call, so much as a blocking get.


On Thu, 17 Nov 2011, Jonas Sicking wrote:
> 
> We can only allow child workers to block on parent workers. Never the 
> other way around.

Indeed. And it would have to be limited to the built-in ports that workers 
have, because regular ports can be shunted all over the place and you 
could end up with a deadlock situation.

It would be easy enough to add a blocking get on DedicatedWorkerGlobalScope.
Is this something for which there's a lot of demand?

   // blocking get
   // no self.onmessage handler needed
   ...
   var message = self.getMessage();
   ...

An alternative is to add continuations to the platform:

   // continuation
   // (this is not a formal proposal, just a illustration of the concept)
   var message;
   self.onmessage = function (event) {
     message = event;
     signal('got message'); // queues a task to resume from yieldUntil()
   };
   ...
   yieldUntil('got message');
   ...

This would be a more general solution and would be applicable in many 
other parts of the platform. As we get more and more async APIs, I think 
it might be worth considering adding this.

We could add it to HTML as an API rather than adding it to JS as a 
language construct. It would be relatively easy to define, if much harder 
to implement:

   yieldUntil(id) - spin the event loop until the signal() API unblocks 
                    this script

   signal(id)     - unblock the script with the oldest invokation of
                    yieldUntil() called with the given ID, if any

Given our definition of "spin the event loop", this doesn't even result, 
per the spec, in nested event loops or anything like that. Note that per 
this definition, "signal" just queues a task to resume the earlier script, 
it is not your typical coroutine. That is:

   setTimeout(function () {
     console.log('2');
     signal('test');
     console.log('3');
   }, 1000);
   console.log('1');
   yieldUntil('test');
   console.log('4');

...logs 1, 2, 3, 4, not 1, 2, 4, 3.

Anyone object to me adding something like this? Are there any better 
solutions? Should we just tell authors to get used to the async style?

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Monday, 13 February 2012 19:45:15 GMT

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