On Fri, Sep 12, 2025 at 6:55 PM Eric Rannaud <[email protected]> wrote:
> I'm not sure there is a way to implement a timeout feature for the inner > context without a separate queue. > > > What prevents Node from using the same timeout mechanism when spinning > the main queue? You can trigger an isolate->TerminateExecution or > isolate->RequestInterrupt from any thread. > > > I'm likely (further) reaching the limits of my understanding. What I can > say is that we want the timeout to cover the runtime of code in the inner > context, including microtasks associated with it. With a separate microtask > queue, we can account for the execution time of microtasks: currently, > Evaluate() and PerformCheckpoint() are called while a watchdog is running > in a separate thread, from which TerminateExecution may be called. > > Maybe we could account for the time spent running microtasks from the > inner context in a different way. > I don't think it's helpful to think about this in terms of "runtime of code in the inner context" -- if your inner context starts a (potentially) long task in the outer context, and then awaits its result, then you (maybe?) want the timeout to still kill the inner context despite it not doing anything itself. My personal expectation of a timeout, as a user, is wall-clock time from when the timeout starts, without exact context attribution. - Leszek -- -- v8-dev mailing list [email protected] http://groups.google.com/group/v8-dev --- You received this message because you are subscribed to the Google Groups "v8-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/d/msgid/v8-dev/CAGxd1t_h2YS2vRajMC-gb69mV0AZh0z%3DcQOr9WOFPek6TFsg1w%40mail.gmail.com.
