-
-
Notifications
You must be signed in to change notification settings - Fork 32.2k
Delete stale note about mp.Lock.acquire/SIGINT #120929
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
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the PR! Looking at the tests / history, I don't think it's guaranteed that SIGINT will be handled in threading
:
cpython/Lib/test/test_threadsignals.py
Lines 71 to 79 in 34920f3
@unittest.skipIf(USING_PTHREAD_COND, | |
'POSIX condition variables cannot be interrupted') | |
@unittest.skipIf(sys.platform.startswith('linux') and | |
not sys.thread_info.version, | |
'Issue 34004: musl does not allow interruption of locks ' | |
'by signals.') | |
# Issue #20564: sem_timedwait() cannot be interrupted on OpenBSD | |
@unittest.skipIf(sys.platform.startswith('openbsd'), | |
'lock cannot be interrupted on OpenBSD') |
(I'm not sure how much that's up to date though, e.g. I couldn't reproduce on Alpine)
So it feels like this is still a useful additional guarantee to document. That said, Python did used to always ignore SIGINT in threading, and no longer does, so maybe we should say something like:
This differs from the behaviour of :mod:
threading
where on certain platforms SIGINT is
not guaranteed to be able to interrupt while the equivalent blocking calls are in progress.
That text was from the original when |
(cherry picked from commit 0dcbc83) Co-authored-by: Andrey Mishchenko <[email protected]>
GH-122078 is a backport of this pull request to the 3.13 branch. |
(cherry picked from commit 0dcbc83) Co-authored-by: Andrey Mishchenko <[email protected]>
GH-122079 is a backport of this pull request to the 3.12 branch. |
…-122079) Delete stale note about mp.Lock.acquire/SIGINT (GH-120929) (cherry picked from commit 0dcbc83) Co-authored-by: Andrey Mishchenko <[email protected]>
…-122078) Delete stale note about mp.Lock.acquire/SIGINT (GH-120929) (cherry picked from commit 0dcbc83) Co-authored-by: Andrey Mishchenko <[email protected]>
The note I've deleted in this PR from the
multiprocessing
docs does not seem to be true anymore. (Or I'm misunderstanding something.)