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

Re: Synchronous postMessage for Workers?

From: John J Barton <johnjbarton@johnjbarton.com>
Date: Wed, 15 Feb 2012 08:09:31 -0800
Message-ID: <CAFAtnWxgizF-1TqTcU5GkviEWuADRyYnefScieDYuVNyOJ_9CA@mail.gmail.com>
To: Jonas Sicking <jonas@sicking.cc>
Cc: Glenn Maynard <glenn@zewt.org>, Ian Hickson <ian@hixie.ch>, Joshua Bell <jsbell@chromium.org>, public-webapps@w3.org, David Levin <levin@chromium.org>
On Tue, Feb 14, 2012 at 10:39 PM, Jonas Sicking <jonas@sicking.cc> wrote:
...
> The problem is when you have functions which call yieldUntil. I.e.
> when you have code like this:
>
> function doStuff() {
>  yieldUntil("x");
> };
>
> now what looks like perfectly safe innocent code:
>
> function myFunction() {
>  ... code here ...
>  doStuff();
>  ... more code ...
> }
>
> The myFunction code might look perfectly sane and safe. However since
> the call to doStuff spins the event loop, the two code snippets can
> see entirely different worlds.
>
> Put it another way, when you spin the event loop, not only does your
> code need to be prepared for anything happening. All functions up the
> call stack also has to. That makes it very hard to reason about any of
> your code, not just the code that calls yieldUntil.

This argument makes good sense, but can we make it more concrete and
thus clearer?

What I am fishing for is an example that clearer shows the
yieldUntil() pattern is hard compared to a function call in to a large
library or into the platform and compared to a function call that
passes state fro myFunction() into a closure. Can a function on
another event loop access the private (closure) state of myFunction()
in a way that the other two patterns cannot?

jjb
Received on Wednesday, 15 February 2012 16:10:07 GMT

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