Le 13/08/2013 03:09, David Herman a écrit :
> On Aug 12, 2013, at 5:43 PM, David Bruant <bruant.d at gmail.com> wrote:
>
>>> - I see *no* reasonable alternative to runaway microtask churn other than slow-script dialog.
>> So did Dominic [1]. I suggested something else [2] and he found the idea interesting. What do you think?
> Quoting you from
>
>> [2] https://mail.mozilla.org/pipermail/es-discuss/2013-August/032630.html
> you said:
>
>> Maybe implementations could decide to break a microtask chain, but
>> instead of prompting a dialog, they just break it and call a callback
>> (later, in a different task, not microtask) so that the script knows and
>> can try to recover.
> It is an interesting idea, I missed it the first time around; you might describe it as an asynchronous TimeoutException. I'm thinking about it, but I'm pretty skeptical. It's still effectively preemption semantics. At any nondeterministic (and not portably defined) point, your code can simply be stopped. It's not even clear what the atomicity guarantees would be around valid preemption points in the semantics. For example, can you preempt code halfway through the modification of a 64-bit word? Can you preempt code that hasn't spilled its registers back to memory? Am I scaring you yet? ;-)
It could be decided that preemption can only happen between microtasks. 
That is still preemption, but less scary.

> Even if we could provide a fully well-specified definition for concurrent interruption, I really have no idea how code could ever realistically recover from such an event. The only thing the system tells you is "at some point in some turn we just stopped you from whatever you were doing," and now you're expected to reconstruct your state. This reminds me of exception safety in C++.
I don't have more ideas than you, but the situation is not worse than 
the current slow-script dialog de facto standard.
How do people recover today from when the user click "stop script"?
With what I described, the programmer would have an equivalent 
experience, but this time, we don't bother the user with an annoying 
dialog which choice is almost impossible anyway (you really have to be 
JS-savvy and have deep understanding of the misbehaving webpage to 
decide to continue or end a script just based on file url and line number).
And I drafted a mechanism that might help when trying to recover (but 
I'm really not an expert in these recovery scenarii, so more experts 
people can jump in.)

Note that this idea of a script-controlled timeout could be expanded in 
other places. For instance, DoS is a permanent and assumed threat from 
partially trusted code. With module loaders, the loader could decide 
that a given task/microtask from an untrusted function can never be 
longer than x milliseconds. This way, this threat can be under tight 
control. The module loader could be told anytime a module timed out and 
decide to just kill it if that happens too often, etc.

Also, maybe an equivalent feature could be added to function calls too.
We could have Function.prototype.recoverableApply(this, args, onPreempted)
(maybe recoverableBind too?)
When the user clicks "kill script" during a "recoverable call" , the 
onPreempted function is schedule for a later turn and try to recover 
what it can (but we might have been preempted in one of the situation 
you described above, so... good luck, but that's not worse than today's 
situation)

David

Le 13/08/2013 03:09, David Herman a écrit :
> It is an interesting idea, I missed it the first time around; you might describe it as an asynchronous TimeoutException. I'm thinking about it, but I'm pretty skeptical. It's still effectively preemption semantics. At any nondeterministic (and not portably defined) point, your code can simply be stopped. It's not even clear what the atomicity guarantees would be around valid preemption points in the semantics. For example, can you preempt code halfway through the modification of a 64-bit word? Can you preempt code that hasn't spilled its registers back to memory? Am I scaring you yet? ;-)

It could be decided that preemption can only happen between microtasks. 
That is still preemption, but less scary.

> Even if we could provide a fully well-specified definition for concurrent interruption, I really have no idea how code could ever realistically recover from such an event. The only thing the system tells you is "at some point in some turn we just stopped you from whatever you were doing," and now you're expected to reconstruct your state. This reminds me of exception safety in C++.

I don't have more ideas than you, but the situation is not worse than 
the current slow-script dialog de facto standard.
How do people recover today from when the user click "stop script"?
With what I described, the programmer would have an equivalent 
experience, but this time, we don't bother the user with an annoying 
dialog which choice is almost impossible anyway (you really have to be 
JS-savvy and have deep understanding of the misbehaving webpage to 
decide to continue or end a script just based on file url and line number).
And I drafted a mechanism that might help when trying to recover (but 
I'm really not an expert in these recovery scenarii, so more experts 
people can jump in.)

Note that this idea of a script-controlled timeout could be expanded in 
other places. For instance, DoS is a permanent and assumed threat from 
partially trusted code. With module loaders, the loader could decide 
that a given task/microtask from an untrusted function can never be 
longer than x milliseconds. This way, this threat can be under tight 
control. The module loader could be told anytime a module timed out and 
decide to just kill it if that happens too often, etc.

Also, maybe an equivalent feature could be added to function calls too.
We could have Function.prototype.recoverableApply(this, args, onPreempted)
(maybe recoverableBind too?)
When the user clicks "kill script" during a "recoverable call" , the 
onPreempted function is schedule for a later turn and try to recover 
what it can (but we might have been preempted in one of the situation 
you described above, so... good luck, but that's not worse than today's 
situation)