Hi Leszek, On Friday, September 12, 2025 at 8:43:15 AM UTC-7 [email protected] wrote:
I'm sorry that this will be a short reply to a long and well thought through email, but really the discussion needs to fork at: I now wonder a little bit if the standards folks threw in the concept of multiple microtask queues without a clear use case and it's not really workable as it is. The standard _doesn't_ have a concept of multiple microtask queues (it actually doesn't have a concept of microtasks at all, just "Jobs"). Thank you for the correction. Yes, my interpretation led me to conclude multiple realms => multiple queues. Your explanation is very clarifying. 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. Thanks, Eric -- -- 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/4435f16c-1e35-4598-82bf-f630489ec76bn%40googlegroups.com.
