8000 Queuing tasks on the current thread is too restrictive · Issue #35517 · servo/servo · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
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.

Sign up for GitHub

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

Jump to bottom

Queuing tasks on the current thread is too restrictive #35517

Open
jdm opened this issue Feb 17, 2025 · 1 comment
Open

Queuing tasks on the current thread is too restrictive #35517

jdm opened this issue Feb 17, 2025 · 1 comment
Labels
A-content/script Related to the script thread B-interesting-project Represents work that is expected to be interesting in some fashion I-papercut Small but painful.

Comments

@jdm
Copy link
Member
jdm commented Feb 17, 2025 •
edited
Loading

There have been multiple instances recently of DOM code that has a callback object (Rc<...>) and needs to queue a task to invoke it. Our task queue is built on channels, since script thread events can come from many sources, which means that all queued tasks must fulfill the Send bounds. When we are queueing a task from the same thread that it will run on, however, this is a poor developer experience—it would be much clearer for the task to take ownership of the non-Send data when it is guaranteed that the task will run on the originating thread.

I can imagine three possible solutions:

  1. We create a new type that can wrap a non-Send type and verify that it's only accessed on the original thread. This is very similar to the Trusted type that we use to wrap DOM objects for use in async tasks.
  2. We add a new type for same-thread task sources. This type exposes an API that does not require a Send bound, and uses an unsafe type to pretend the task is sendable under the hood when it interacts with the channel.
  3. We have separate task queues for tasks from other threads vs. tasks from the current thread. The queue for the current thread is a VecDeque rather than a channel, and when the queue transitions from empty->non-empty we enqueue a task that flushes the local queue.

The third solution appeals to me because it requires no extra work from the API user and requires no unsafe code or lying about types.
@jdm jdm added A-content/script Related to the script thread B-interesting-project Represents work that is expected to be interesting in some fashion I-papercut Small but painful. labels Feb 17, 2025
@jdm
Copy link
Member Author
jdm commented Feb 17, 2025

#35418 (comment) is an example of the extra hoops that developers need to jump through right now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
A-content/script Related to the script thread B-interesting-project Represents work that is expected to be interesting in some fashion I-papercut Small but painful.
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@jdm
0