Due to recent changes, a Thread doesn't know that it's over before
someone calls .join() or .is_alive(). That meant repr(Thread)
continued to include "started" (and not "stopped") before one of
those methods was called, even if hours passed since the thread
ended.
Repaired that.
Antoine Pitrou found a variation that worked for him on the
thread+fork tests, and added an important
self._is_stopped = True
to the after-fork code. I confess I don't know why things passed
before. But then mixing fork with threads is insane ;-)
The fix for issue 18808 left us checking two things to be sure a Thread
was done: an Event (._stopped) and a mutex (._tstate_lock). Clumsy &
brittle. This patch removes the Event, leaving just a happy lock :-)
The bulk of the patch removes two excruciating tests, which were
verifying sanity of the internals of the ._stopped Event after a fork.
Thanks to Antoine Pitrou for verifying that's the only real value
these tests had.
One consequence of moving from an Event to a mutex: waiters (threads
calling Thread.join()) used to block each on their own unique mutex
(internal to the ._stopped event), but now all contend on the same
mutex (._tstate_lock). These approaches have different performance
characteristics on different platforms. I don't think it matters in
this context.
test_is_alive_after_fork is failing on some old Linux kernels, but
passing on all newer ones. Since virtually anything can go wrong
with locks when mixing threads with fork, replace the most likely
cause with a redundant simple data member.
