Re: Synchronous postMessage for Workers?

On Wed, Feb 15, 2012 at 9:37 AM, Mark S. Miller <erights@google.com> wrote:

> On Wed, Feb 15, 2012 at 8:09 AM, John J Barton <
> johnjbarton@johnjbarton.com> wrote:
>
>> On Tue, Feb 14, 2012 at 10:39 PM, Jonas Sicking <jonas@sicking.cc> wrote:
>>
> [...]
>
>> > function doStuff() {
>> >  yieldUntil("x");
>> > };
>> >
>> > now what looks like perfectly safe innocent code:
>> >
>> > function myFunction() {
>> >  ... code here ...
>> >  doStuff();
>> >  ... more code ...
>>
> [...]
>
>> What I am fishing for is an example [...] a function on
>>
>> another event loop access the private (closure) state of myFunction()
>> in a way that the other two patterns cannot?
>>
>
>   function makeStatusHolder(status) {
>     var listeners = [];
>     return Object.freeze({
>       addListener: function(newListener) { listeners.add(newListener); },
>       getStatus: function() { return status; },
>       setStatus: function(newStatus) {
>         status = newStatus;
>         listeners.forEach(function(listener) {
>           listener.statusChanged(newStatus);
>         });
>       }
>     });
>   }
>
> This pattern is unsafe of any of the listeners might call back into the
> statusHolder during notification (see Fig 13.2 of my thesis). However, we
> may judge a particular usage ok if we know that none of the listeners has
> access, directly or indirectly, to this statusHolder itself.
> Under maintenance, one of these listeners may be revised to use  yieldUntil
> to wait from a result from a foreign worker that itself does not have
> access to this statusHolder, thereby not violating the assumption above.
> Nevertheless, if this event loop is receptive to external events while it
> is waiting, this pattern becomes unsafe.
>
> In the absence of yieldUntil, the revised listener can gain most of the
> same brevity and expressivity benefits by using <
> http://wiki.ecmascript.org/doku.php?id=strawman:async_functions>
>

Concretely, combining the previous examples:

  var doStuff = Q.async(function*() {
    yield until("x");
  });

  var myListener = Q.async(function*(newStatus) {
   ... code here ...
   yield doStuff();
   ... more code ...
  });

Of course, if we revise the notification loop itself to be an async
function yielding on each notification, then we've recreated all the
original hazards. But there is no reason to do so.



> (Already supported by Kris' implementation using FF generators). Though
> this provides most of the benefits of yieldUntil, it does not cause these
> dangers. The notification loop runs to completion in the current turn. The
> listener proceeds from the yield point in a separate turn. Any
> interleavings that happen during the yield also happen in separate turns
> after the notification loop completes.
>
> --
>     Cheers,
>     --MarkM
>



-- 
    Cheers,
    --MarkM