Skip to content

Conversation

@x42005e1f
Copy link
Contributor

This is a simple PR that fixes #720 by removing loop._ready_len in favor of len(loop._ready). The attribute was probably added as a premature optimization (it does not affect performance even in edge cases), but it leads to race conditions both between worker threads calling loop.call_soon_threadsafe() and between any such worker thread and the event loop, since loop._ready_len is updated in a non-thread-safe manner (free-threading).

@x42005e1f x42005e1f changed the title Fix race conditions on _ready_len Fix race conditions on loop._ready_len Jan 19, 2026
Copy link
Member

@fantix fantix left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Perfecto!

@x42005e1f
Copy link
Contributor Author

x42005e1f commented Jan 19, 2026

The test failure looks like a load on CI/CD. Compared to #719, some jobs run faster, some run at the same speed, and some run slower. The problem with test_process_streams_redirect() is that it also captures asyncio messages in stderr that a task's callback is taking too long (probably due to slow context switching between threads/processes under high load on the system scheduler?), so it is flaky. The warning is logged from _on_idle(), so it is unrelated to the changes in this PR.

@fantix fantix merged commit 5910a18 into MagicStack:master Jan 19, 2026
48 of 51 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

loop.call_soon_threadsafe() behaves as non-thread-safe in free-threading

2 participants