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
Right now when you spawn a SingleThreaded task, its scheduler is given a 'friend' scheduler to which it sends work that can't be executed. This creates a situation where threads that are rejecting a lot of work serialize a bunch of tasks through a single other thread which may not be able to run that work in a reasonable time.
Instead of sending work to a single friend it needs to either go back into the general pool, or (better) single-threaded schedulers should add their work queues to the global pool of work queues for stealing.
The text was updated successfully, but these errors were encountered:
We could band-aid over one of the most common deadlocking problems this causes by making the runtime detect situations where a single-threaded scheduler spawns another single-threaded scheduler (creating a chain of single-threaded friends), and doing the spawn from the friend.
uninlined_format_args: do not inline argument with generic parameters
Fixrust-lang#10339
---
changelog: FP: [`uninlined_format_args`]: No longer lints for arguments with generic parameters
[rust-lang#10343](rust-lang/rust-clippy#10343)
<!-- changelog_checked -->
Right now when you spawn a SingleThreaded task, its scheduler is given a 'friend' scheduler to which it sends work that can't be executed. This creates a situation where threads that are rejecting a lot of work serialize a bunch of tasks through a single other thread which may not be able to run that work in a reasonable time.
Instead of sending work to a single friend it needs to either go back into the general pool, or (better) single-threaded schedulers should add their work queues to the global pool of work queues for stealing.
The text was updated successfully, but these errors were encountered: