On 20/10/2011, at 18:38, Brendan Eich wrote:
> 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.
I don't see how it's different: next to f() it says //might suspend execution:
the assert_invariants() at the next line might run in another turn of the event
loop (when f() resumes), just as the callback does.
?
--
Jorge.
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
