Re: Synchronous postMessage for Workers?

Le 13/02/2012 20:44, Ian Hickson a écrit :
> 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?
If a web author does a typo (and we all know that especially with a
string-based API, it will happen or people will generate dynamically the
strings), what happens? Are you just blocked can can't resume after the
yieldUntil?

> Are there any better solutions?
"yield" as a keyword is considered being added to ECMAScript 6:
http://wiki.ecmascript.org/doku.php?id=harmony:generators#generator_functions
Web browsers will start implementing this one alongside with other new
ECMAScript features.
The yieldUntil/signal API would be probably a duplication of this.

I also recommand having a look at Dave Herman's Task.js http://taskjs.org/

> Should we just tell authors to get used to the async style?
I think we should. More constructs are coming in ECMAScript. Things
related to language concurrency should probably be left to the core
language unless there is an extreme need (which there isn't as far as I
know).

David

Received on Tuesday, 14 February 2012 07:02:56 UTC