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 ?
Because, if there's a callback involved, the invariants are not invariant
anymore, and that's the sole argument node.js guys keep harping on again and
again (wrongly imo) against any way of suspending/resuming f().
For example:
assert_invariants();
function callBack () {
assert_invariants(); // perhaps yes, perhaps no. There's no guarantee.
};
setTimeout(callBack, 1e3);
return;
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;
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 ?
--
Jorge.
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
