This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author gregory.p.smith
Recipients Rhamphoryncus, eryksun, gregory.p.smith, gvanrossum, jdemeyer, steve.dower, vstinner
Date 2019-04-12.18:52:29
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
We can remove ancient Irix and LinuxThreads hacks from our codebase.

The best way to shake issues of this sort out is to remove it and watch for issues on supported buildbots and during beta releases.  I don't expect any fallout from this one.

Other places this check _could_ have come up without us realizing it... if a signal handler setup persisted into a quasi-forked process (vfork) this check would prevent that oddball dangerous state of a child process from doing signal processing until after _PySignal_AfterFork was called to reset main_pid.

but trip_signal() is already safe in crazy async signal safe contexts so I don't see a problem there.  if it happened to write to a wakeup.fd that was shared by the parent and child even that shouldn't be an issue.  A vfork()ed process is about to exec or die anyways (no other actions are supported) - never go back to running Python code.
Date User Action Args
2019-04-12 18:52:29gregory.p.smithsetrecipients: + gregory.p.smith, gvanrossum, Rhamphoryncus, vstinner, jdemeyer, eryksun, steve.dower
2019-04-12 18:52:29gregory.p.smithsetmessageid: <>
2019-04-12 18:52:29gregory.p.smithlinkissue36601 messages
2019-04-12 18:52:29gregory.p.smithcreate