Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Event-loop should not block when microtask queue is not empty #26700

Open
gterzian opened this issue May 29, 2020 · 0 comments
Open

Event-loop should not block when microtask queue is not empty #26700

gterzian opened this issue May 29, 2020 · 0 comments
Labels
A-content/script Related to the script thread

Comments

@gterzian
Copy link
Member

gterzian commented May 29, 2020

Step 1 of the event-loop processing model reads(emphasis mine):

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.

We have two places where this is implemented:

  1. https://github.com/servo/servo/blob/master/components/script/script_thread.rs#L1357
  2. https://github.com/servo/servo/blob/d7d56454b07b70e3d9b2e3746ea1b2a1a1f05b7f/components/script/dom/abstractworkerglobalscope.rs

In both places, we actually run a different algorithm where we:

  1. block on a select!
  2. Run a task(or handle another type of message)
  3. Perform a microtask checkpoint.
  4. 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).

@gterzian gterzian added the A-content/script Related to the script thread label May 29, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-content/script Related to the script thread
Projects
None yet
Development

No branches or pull requests

1 participant