Skip to content

gh-144706: docs note about combining RLock and signal handlers #144736

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.

Sign up for GitHub

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

Merged
ZeroIntensity merged 6 commits into from
Feb 12, 2026
Merged

gh-144706: docs note about combining RLock and signal handlers #144736

Changes from 5 commits
Commits
Show all changes
6 commits
Select commit Hold shift + click to select a range
fe1db59
Docs: note about combining RLock and signal handlers
robsdedude Feb 12, 2026
57ce53f
Review feedback
robsdedude Feb 12, 2026
21cc735
Move warning to signal module and rephrase
robsdedude Feb 12, 2026
3684c03
Fix typo
robsdedude Feb 12, 2026
e318c30
Wording
robsdedude Feb 12, 2026
052972a
Review feedback
robsdedude Feb 12, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
6 changes: 6 additions & 0 deletions Doc/library/signal.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -68,6 +68,12 @@ the synchronization primitives from the :mod:`threading` module instead.

Besides, only the main thread of the main interpreter is allowed to set a new signal handler.

.. warning::

Synchronization primitives such as :class:`threading.Lock` should not be used
within signal handlers. Because blocking synchronization calls can be
interrupted by signals, such usage can lead to surprising dead locks.
Copy link
Copy Markdown
Member

@ZeroIntensity ZeroIntensity Feb 12, 2026

Choose a reason for hiding this comment

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

I don't think we need to be specific:

Suggested change
Synchronization primitives such as :class:`threading.Lock` should not be used
within signal handlers. Because blocking synchronization calls can be
interrupted by signals, such usage can lead to surprising dead locks.
Synchronization primitives such as :class:`threading.Lock` should not be used
within signal handlers. Doing so can lead to deadlocks.

Copy link
Copy Markdown
Contributor Author

@robsdedude robsdedude Feb 12, 2026

Choose a reason for hiding this comment

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

Thanks for the suggestion. I think if I were to read this for the first time I wouldn't understand the issue. And understanding something makes it easier to remember, too. I'd probably be thinking something like "well yeah, using synchronization primitives in general can lead to deadlocks. So what's different here?"

Copy link
Copy Markdown
Member

@ZeroIntensity ZeroIntensity Feb 12, 2026

Choose a reason for hiding this comment

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

Let's say "unexpected deadlocks" then. The situation in the issue is one of many problems that come up when using synchronization primitives in signal handlers, so it's misleading to say that interruptibility is the only concern.



Module contents
---------------
Expand Down
Loading