Re: Synchronous postMessage for Workers?

On Wed, Feb 15, 2012 at 11:09 AM, John J Barton
<johnjbarton@johnjbarton.com> wrote:
> 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?

Consider the following code

setInterval(function () {
  ... non-reentrant-safe code ...
  doStuff();
  ... non-reentrant-safe code ...
}, 100);

This code is perfectly safe and fine. Unless doStuff spins the event
loop. If doStuff spins the event loop you may or may not break the
invariants that the callback relies upon.

The same thing would happen if the function wasn't anonymous and
doStuff explicitly called it. But avoiding to explicitly call a
function is pretty easy. As long as the page isn't intentionally
trying to hack itself it's a pretty safe thing to rely on.

/ Jonas

Received on Thursday, 16 February 2012 06:24:47 UTC