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.