You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Let taskQueue be one of the event loop's task queues, chosen in an implementation-defined manner, with the constraint that the chosen task queue must contain at least one runnable task. If there is no such task queue, then jump to the microtasks step below.
In both places, we actually run a different algorithm where we:
block on a select!
Run a task(or handle another type of message)
Perform a microtask checkpoint.
Go back to 1.
So the problem there is that while we block at 1. we won't perform the "If there is no such task queue, then jump to the microtasks step below." part of the processing model, instead we'll just block until a message comes in, even if we do have microtasks ready to execute.
I think we're not noticing this a lot because there are usually lots of messages coming in, but it might also be a hidden performance problem, since in cases were we could immediately skip to the microtask checkpoint, now we will instead wait until an unrelated messages wakes-up the event-loop.
The actual use case were this can happen is where a microtask queues other microtasks, while the microtask checkpoint is not re-entrant so those subsequent tasks will only execute at the next checkpoint.
So I think in both cases, we could add a "microtask-ready" channel to the select, and ensure it has a message when the microtask queue is not empty(send a message on it when the first microtask in an iteration of the event-loop is queued).
The text was updated successfully, but these errors were encountered:
Step 1 of the event-loop processing model reads(emphasis mine):
We have two places where this is implemented:
In both places, we actually run a different algorithm where we:
select!
So the problem there is that while we block at 1. we won't perform the "If there is no such task queue, then jump to the microtasks step below." part of the processing model, instead we'll just block until a message comes in, even if we do have microtasks ready to execute.
I think we're not noticing this a lot because there are usually lots of messages coming in, but it might also be a hidden performance problem, since in cases were we could immediately skip to the microtask checkpoint, now we will instead wait until an unrelated messages wakes-up the event-loop.
The actual use case were this can happen is where a microtask queues other microtasks, while the microtask checkpoint is not re-entrant so those subsequent tasks will only execute at the next checkpoint.
So I think in both cases, we could add a "microtask-ready" channel to the select, and ensure it has a message when the microtask queue is not empty(send a message on it when the first microtask in an iteration of the event-loop is queued).
The text was updated successfully, but these errors were encountered: