On Oct 20, 2011, at 6:44 AM, Jorge wrote:
> On 19/10/2011, at 23:34, Brendan Eich wrote:
>>
>> The other objection is that (ignoring some evil native APIs such as sync
>> XHR) JS has run-to-completion execution model now. You can model
>>
>> assert_invariants();
>> f();
>> assert_invariants_not_affected_by_f_etc();
>>
>> where "etc" means functions called from f. No data races, no preemption
>> points even if "voluntary" -- the immediately preempted function may have
>> volunteered, but in programming in the large, the sum of its ancestors in
>> all call graphs may well *not* have volunteered to lose their invariants.
>>
>> This second objection is not an implementor issue, rather a
>> security/integrity/pedagogy concern. It's a big one too.
>
> Is run-to-completion so important, really ?
Yes.
Birdie: You looking for an answer or an argument?
Margo Channing: An answer.
Birdie: No.
Margo Channing: Why not?
Birdie: Now you want an argument.
> Because, if there's a callback involved, the invariants are not invariant
> anymore,
What do you mean by "if there's a callback involved"?
What I sketched showed a function f being called. There is no preemption point
under a function call. If I had written g(function callback() {...})) then the
... would perhaps have run in a separate event loop turn. So what? That's not
issue.
> and that's the sole argument node.js guys keep harping on again and again
> (wrongly imo) against any way of suspending/resuming f().
You are changing the example to something not at issue. Callbacks run in
separate turns (by convention, better if defined as always, as for
setTimeout(0)).
> For example:
>
> assert_invariants();
> function callBack () {
> assert_invariants(); // perhaps yes, perhaps no. There's no guarantee.
> };
> setTimeout(callBack, 1e3);
> return;
Here again, as with 'yield', the programmer explicitly opted out of
run-to-completion. The reader can see the 'function callBack' head and braced
body. This signals that the code is deferred and won't be executed until
invocation.
> So, as far as I can see, when dealing with asynchronous code, the risks in
> that code are equivalent to the risks in this code:
>
> assert_invariants();
> f(); //might suspend execution
> assert_invariants(); // perhaps yes, perhaps no. There's no guarantee either.
> return;
See above. You're now making every single call expression in an entire JS
codebase potentially a preemption point. That's bad for reasoning about
invariants, therefore bad for correctness, including security.
> But, in the first case you can't try/catch where it matters (which is
> annoying), and you can't write your code linearly as if it were synchronous,
> which is a (bit of a) pain.
>
> So I must be missing something. What's it ?
You changed the example to defer evaluation with a callback.passed down to
another function and then asserted the changed example was no different from a
direct call with no callback. That's different, because the function wrapping
explicitly defers evaluation of the function body.
/be
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
