On Aug 12, 2013, at 5:43 PM, David Bruant <bruan...@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? ;-) 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++. Dave _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
