-
-
Notifications
You must be signed in to change notification settings - Fork 43
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
Spawning more processes than a channel can handle seems to result in them locking up #539
Comments
Digging deeper it seems the channel size is a red herring, because if we remove the My guess is that the timeout worker either deadlocks somehow, or loses processes to reschedule. |
This comment was marked as off-topic.
This comment was marked as off-topic.
Some notes from debugging this:
The script I'm using:
And with this runtime patch: diff --git a/rt/src/scheduler/timeout_worker.rs b/rt/src/scheduler/timeout_worker.rs
index 2bcc6fa1..dd9a49e4 100644
--- a/rt/src/scheduler/timeout_worker.rs
+++ b/rt/src/scheduler/timeout_worker.rs
@@ -149,6 +149,10 @@ impl TimeoutWorker {
let (expired, time_until_expiration) =
inner.timeouts.processes_to_reschedule();
+ for _ in 0..expired.len() {
+ println!("rescheduling");
+ }
+
scheduler.schedule_multiple(expired);
time_until_expiration
} |
The problem doesn't appear to be due to OS threads going to sleep when there's work available, as simply disabling sleeping entirely (so they just spin) doesn't solve the problem. |
I think I found the problem: in |
Please describe the bug
Reading through https://pkolaczk.github.io/memory-consumption-of-async/, I decided to implement something similar in Inko (but using a two second sleep to get the results faster):
When running this with 340 or more processes (
inko run test.inko 340
), the program seems to lock up in thechan.receive
loop. Weirdly enough it will work just fine when using339
as the argument.My guess is that we're deadlocking on the channels somewhere, or that too many threads are fighting over the mutex.
Please list the exact steps necessary to reproduce the bug
Save the above script to
test.inko
and run it usinginko run test.inko 340
.Operating system
Fedora Silverblue 38
Inko version
main
Rust version
1.68.2
The text was updated successfully, but these errors were encountered: