On Thu, Oct 20, 2011 at 9:44 AM, Jorge <[email protected]> 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 ?
>
> 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 ?
>
Yes, I think what you're missing is the semantics intended by
run-to-completion. You claim the two cases above are equivalent but that's
not true at all. There's a *huge *difference between explicit preemption and
implicit preemption -- the latter is a hazard, plain and simple. Let's not
mix the two up and jeopardize getting the former into the language.
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
