* bpo-31234: Join threads in tests (#3572)
Call thread.join() on threads to prevent the "dangling threads"
warning.
(cherry picked from commit 18e95b4176)
* bpo-31234: Join threads in test_hashlib (#3573)
* bpo-31234: Join threads in test_hashlib
Use thread.join() to wait until the parallel hash tasks complete
rather than using events. Calling thread.join() prevent "dangling
thread" warnings.
* test_hashlib: minor PEP 8 coding style fixes
(cherry picked from commit 8dcf22f442)
* bpo-31234: Join threads in test_threading (#3579)
Call thread.join() to prevent the "dangling thread" warning.
(cherry picked from commit b8c7be2c52)
* bpo-31234: Join threads in test_queue (#3586)
Call thread.join() to prevent the "dangling thread" warning.
(cherry picked from commit 167cbde50a)
* bpo-31234: Join timers in test_threading (#3598)
Call the .join() method of threading.Timer timers to prevent the
"threading_cleanup() failed to cleanup 1 threads" warning.
(cherry picked from commit da3e5cf961)
test_is_alive_after_fork() now joins directly the thread to avoid the
following warning added by bpo-30357:
Warning -- threading_cleanup() failed to cleanup 0 threads
after 2 sec (count: 0, dangling: 21)
Use also a different exit code to catch generic exit code 1.
(cherry picked from commit f8d05b3a24)
Issue #27558: Fix a SystemError in the implementation of "raise" statement.
In a brand new thread, raise a RuntimeError since there is no active
exception to reraise.
Patch written by Xiang Zhang.
Fix a crash when a generator is created in a C thread that is destroyed while
the generator is still used. The issue was that a generator contains a frame,
and the frame kept a reference to the Python state of the destroyed C thread.
The crash occurs when a trace function is setup.
crash when a generator is created in a C thread that is destroyed while the
generator is still used. The issue was that a generator contains a frame, and
the frame kept a reference to the Python state of the destroyed C thread. The
crash occurs when a trace function is setup.
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.
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.
Note that this is a potentially disruptive change since it may
release some system resources which would otherwise remain
perpetually alive (e.g. database connections kept in thread-local
storage).
Miss Islington (bot)
Victor Stinner
Xiang Zhang
Xavier de Gaye
Serhiy Storchaka
Martin Panter
Yury Selivanov
Berker Peksag
Tim Peters
Antoine Pitrou
Andrew Svetlov
Charles-François Natali
Łukasz Langa
R David Murray
Stefan Krah
Benjamin Peterson
Jesus Cea