Re: Synchronous postMessage for Workers?

On Tue, Feb 14, 2012 at 10:07 AM, Jonas Sicking <jonas@sicking.cc> wrote:

> Spinning the event loop is very bug prone. When calling the yieldUntil
> function basically anything can happen, including re-entering the same
> code. Protecting against the entire world changing under you is very
> hard. Add to that that it's very racy. I.e. changes may or may not
> happen under you depending on when exactly you call yieldUntil, and
> which order events come in.
>

I don't think this:

function() {
    f1();
    yieldUntil(condition);
    f2();
}

is any more racy than this:

function() {
    f1();
    waitForCondition(function() {
        f2();
    });
}

The order of events with yieldUntil depends on when you yield, but the same
is true when you return and continue what you're doing from a callback.  I
don't believe it's any more bug-prone than the equivalent callback-based
code, either.  I believe continuations are less error prone than callbacks,
because it leads to code that's simpler and easier to understand.

An alternative way of defining it, rather than spinning the event loop,
might be to store the JS call stack (eg. setjmp), then to return undefined
to the original native caller.  When the condition is signalled, resume the
call stack (from a new native caller).  This would mean that if you yield
from an event handler (or any other callback), the event dispatch would
continue immediately, as if the event handler returned; when your code is
resumed, you'd no longer be inside event dispatch (eg. you can't call
stopPropagation on an event after yielding).  That makes sense to me, since
dispatching events shouldn't block, though it would probably surprise
people.

-- 
Glenn Maynard