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 1 commit
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/threading.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -840,6 +840,12 @@ the lock to an unlocked state and allows another thread blocked in
must have a release in the thread that has acquired the lock. Failing to
call release as many times the lock has been acquired can lead to deadlock.

.. tip::
Comment thread
robsdedude marked this conversation as resolved.
Outdated

Because lock acquisition can be interrupted by signals, sharing reentrant
locks between :mod:`signal` handlers and the main thread can lead to
surprising behavior. Therefore, this is generally not recommended.
Copy link
Copy Markdown

@xBZZZZ xBZZZZ Feb 12, 2026

Choose a reason for hiding this comment

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

surprising behavior

any other surprise that is not main thread waiting forever for itself to release RLock?

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.

  1. This isn't limited to re-entrant locks.
  2. "generally not recommended" is not strong enough -- I can't think of a case where it's thread-safe to use locks in signal handlers.

Copy link
Copy Markdown
Contributor Author

@robsdedude robsdedude Feb 12, 2026 •
edited
Loading

Choose a reason for hiding this comment

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

  1. You are right, I shall fix.
  2. sharing a synchronization primitive between the signal handler and some thread other than the main thread should work just fine, shouldn't it? Anyway, with regards to the main thread only, I can't think of a case either.

Copy link
Copy Markdown

@xBZZZZ xBZZZZ Feb 12, 2026

Choose a reason for hiding this comment

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

This isn't limited to re-entrant locks.

what is surprising about normal locks (like returned by _thread.allocate_lock())?

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.

sharing a synchronization primitive between the signal handler and some thread other than the main thread should work just fine, shouldn't it?

I think you're missing the point. It might work right now, but using locks in signal handlers is not something we want to encourage or claim to support. We may want to change how we handle signals or what they affect someday.

what is surprising about normal locks (like returned by _thread.allocate_lock())?

By acquiring a lock in a signal handler, the lock is subject to deadlocks for any signal handled by the main thread. For example:

  1. Main thread acquires a lock.
  2. User sends signal.
  3. The signal handler is invoked, which tries to acquire that lock.
  4. Deadlock!

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.

I think you're missing the point. It might work right now, but using locks in signal handlers is not something we want to encourage or claim to support. We may want to change how we handle signals or what they affect someday.

Alright. In such case, I think this warning belongs into the signal module instead.



.. class:: RLock()

Expand Down
Loading