Skip to content

gh-109917: Fix concurrent.future ProcessPoolExecutor locks #110137

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

Closed
wants to merge 4 commits into from

Conversation

vstinner
Copy link
Member

@vstinner vstinner commented Sep 30, 2023

vstinner and others added 3 commits September 30, 2023 10:48
…p.wakeup()

Replace test_gh105829_should_not_deadlock_if_wakeup_pipe_full() test
which was mocking too many concurrent.futures internals with a new
test_wakeup() functional test.

Co-Authored-By: elfstrom <[email protected]>
Add a lock to _ThreadWakeup which is used internally by _ThreadWakeup
methods to serialize method calls to make the API thread safe.

No longer use the shutdown lock to access _ThreadWakeup.
@vstinner
Copy link
Member Author

vstinner commented Sep 30, 2023

@elfstrom @tomMoral: This change address the issue described by @elfstrom in #109917 (comment).

This PR is based on PR gh-110129. I would prefer to first merge PR gh-110129 fix, and then see if this additional lock makes things safer... or worse :-)

For me it's suspicious that the code is full of looooong comments explaining that: "please trust me, no lock is needed because (...). it /should/ be ok...".

@vstinner vstinner marked this pull request as draft September 30, 2023 20:49
@vstinner vstinner closed this Oct 3, 2023
@vstinner vstinner deleted the cf_wakeup_lock branch October 3, 2023 16:09
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant