-
-
Notifications
You must be signed in to change notification settings - Fork 2.5k
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
Datagram sockets do not appear to participate in cooperative multitasking #5946
Comments
Thanks, it looks like this codepath was indeed never instrumented with budgeting. I'll self-assign and set up a PR. I think I know of a few other things that have this issue. |
@NoraCodes can you confirm the issue is resolved on your machine using the branch in PR #5967? |
With a slight modification, I was able to confirm that this issue also affects UDP sockets. The fix proposed in #5967 does resolve the issue on my machine. |
This is now in progress. |
Fixes #5946, #4782. This change adds budgeting to most of the remaining unbudgeted IO operations which can complete instantly, including datagram send/recv operations and listener socket accepts. This is particularly significant for scenarios in which resource limits are hit, as it can be common for things like listener tasks to spin when receiving errors and just log them, busy looping worker threads which might otherwise be handling existing connections and closing them. This can also sometimes lead to complex failure scenarios within datagram systems experiencing resource exhaustion.
Fixes #5946, #4782. This change adds budgeting to most of the remaining unbudgeted IO operations which can complete instantly, including datagram send/recv operations and listener socket accepts. This is particularly significant for scenarios in which resource limits are hit, as it can be common for things like listener tasks to spin when receiving errors and just log them, busy looping worker threads which might otherwise be handling existing connections and closing them. This can also sometimes lead to complex failure scenarios within datagram systems experiencing resource exhaustion.
Fixes #5946. Fixes #4782. This change adds budgeting to most of the remaining unbudgeted IO operations which can complete instantly, including datagram send/recv operations and listener socket accepts. This is particularly significant for scenarios in which resource limits are hit, as it can be common for things like listener tasks to spin when receiving errors and just log them, busy looping worker threads which might otherwise be handling existing connections and closing them. This can also sometimes lead to complex failure scenarios within datagram systems experiencing resource exhaustion.
Fixes #5946. Fixes #4782. This change adds budgeting to most of the remaining unbudgeted IO operations which can complete instantly, including datagram send/recv operations and listener socket accepts. This is particularly significant for scenarios in which resource limits are hit, as it can be common for things like listener tasks to spin when receiving errors and just log them, busy looping worker threads which might otherwise be handling existing connections and closing them. This can also sometimes lead to complex failure scenarios within datagram systems experiencing resource exhaustion.
Fixes #5946. Fixes #4782. This change adds budgeting to most of the remaining unbudgeted IO operations which can complete instantly, including datagram send/recv operations and listener socket accepts. This is particularly significant for scenarios in which resource limits are hit, as it can be common for things like listener tasks to spin when receiving errors and just log them, busy looping worker threads which might otherwise be handling existing connections and closing them. This can also sometimes lead to complex failure scenarios within datagram systems experiencing resource exhaustion.
Version
tokio 1.31.0
Platform
uname -a
:Linux enterprise 5.15.0-78-generic #85-Ubuntu SMP Fri Jul 7 15:25:09 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux
Description
It seems like Unix datagram sockets don't correctly participate in cooperative multitasking. When a task continuously recv()s from a Unix datagram socket and there is always a datagram available in the socket, the recv() never blocks, the runtime never forces it to yield and the task never yields. Therefore, other tasks never have an opportunity to run.
In the following small program, I expect to see the debug representation of a std::time::SystemTime printed about every 250ms. When receiving an endless stream of Unix datagrams from 2 or 3 other processes running full tilt, I instead see one every second or every few seconds.
Our example uses a single-threaded runtime, but it also affects a multi-threaded runtime, which we observed as inconsistent but common delays in other tasks being run that happened to be scheduled on the same thread as the datagram recv() task.
This is the output with the explicit yield, and what I would expect:
This is the output without the explicit yield, showing that the timer task is starved of execution time
Co-authored with @jvranish
The text was updated successfully, but these errors were encountered: