microtask timeouts (was Re: setImmediate)

Rafael Weinstein rafaelw at google.com
Mon Aug 12 18:24:48 PDT 2013


FWIW,

I very much agree with Dave on this point. My conceptual model for
microtask work is just a re-ordering of work which otherwise would
have run synchronously, but wanted to be run with a fresh stack.

Microtask non-termination should not be different from "regular"
script non-termination.

On Mon, Aug 12, 2013 at 6:09 PM, David Herman <dherman at mozilla.com> wrote:
> 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? ;-)
>
> 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 at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss


More information about the es-discuss mailing list