[issue35423] Signal handling machinery still relies on "pending calls".

Change by Eric Snow : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker ___ ___

[issue35423] Signal handling machinery still relies on "pending calls".

Eric Snow added the comment: New changeset fdf282d609fd172d52b59a6f1f062eb701494528 by Eric Snow in branch 'master': bpo-35423: Stop using the "pending calls" machinery for signals. (gh-10972) https://github.com/python/cpython/commit/fdf282d609fd172d52b59a6f1f062eb701494528 --

[issue35423] Signal handling machinery still relies on "pending calls".

Change by Eric Snow : -- nosy: +emilyemorehouse ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue35423] Signal handling machinery still relies on "pending calls".

Eric Snow added the comment: Correct. The remaining call to Py_AddPendingCall in the signal-handling code is fine. This issue is only indirectly related. I suppose you could consider it a follow-up to #30703. The PR for that issue (GH-2415) switches from using pending calls for signal

[issue35423] Signal handling machinery still relies on "pending calls".

Change by Eric Snow : -- keywords: +patch pull_requests: +10214 stage: needs patch -> patch review ___ Python tracker ___ ___

[issue35423] Signal handling machinery still relies on "pending calls".

STINNER Victor added the comment: In the master branch, the signal handler only uses pending calls to report error on writing into the "wakeup_fd" (fd or socket handle): commit c08177a1ccad2ed0d50898c2731b518c631aed14 Author: Antoine Pitrou Date: Wed Jun 28 23:29:29 2017 +0200

[issue35423] Signal handling machinery still relies on "pending calls".

New submission from Eric Snow : For a while now the signal handling machinery has piggy-backed on ceval's "pending calls" machinery (e.g. Py_AddPendingCall). This is a bit confusing. It also increases the risk with unrelated changes to the pending calls code. -- assignee: eric.snow