* bpo-6532: Make the thread id an unsigned integer.
From C API side the type of results of PyThread_start_new_thread() and
PyThread_get_thread_ident(), the id parameter of
PyThreadState_SetAsyncExc(), and the thread_id field of PyThreadState
changed from "long" to "unsigned long".
* Restore a check in thread_get_ident().
threading.Lock.acquire(), threading.RLock.acquire() and socket operations now
use a monotonic clock, instead of the system clock, when a timeout is used.
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.
* Rename time.steady() to time.monotonic()
* On Windows, time.monotonic() uses GetTickCount/GetTickCount64() instead of
QueryPerformanceCounter()
* time.monotonic() uses CLOCK_HIGHRES if available
* Add time.get_clock_info(), time.perf_counter() and time.process_time()
functions
The public names (Thread, Condition, etc.) used to be factory functions
returning instances of hidden classes (_Thread, _Condition, etc.),
because (if Guido recalls correctly) this code pre-dates the ability to
subclass extension types.
It is now possible to inherit from Thread and other classes, without
having to import the private underscored names like multiprocessing did.
A doc update will follow: a patch is under discussion on the issue.
thread implementation.
Skip test_lock_acquire_interruption() and test_rlock_acquire_interruption() of
test_threadsignals if a thread lock is implemented using a POSIX mutex and a
POSIX condition variable. A POSIX condition variable cannot be interrupted by a
signal (e.g. on Linux, the futex system call is restarted).
and multiprocessing.Process constructors in order to override the
default behaviour of inheriting the daemonic property from the current
thread/process.
deletes its _block attribute, deal with that. This prevents an uncaught
exception in a thread during test_thread.
This refactors a bit to better match what I did in the r87727 backport to 2.7.
needed to be reinitialized after fork(). Adds tests to confirm that they are
and that a potential deadlock and crasher bug are fixed (platform dependant).
module now takes an optional timeout argument in seconds. Timeout support
relies on the system threading library, so as to avoid a semi-busy wait
loop.
svn+ssh://pythondev@svn.python.org/python/trunk
........
r78517 | gregory.p.smith | 2010-02-28 10:36:09 -0800 (Sun, 28 Feb 2010) | 3 lines
Issue #7481: When a threading.Thread failed to start it would leave the
instance stuck in initial state and present in threading.enumerate().
........
default when instantiating a `Threading.RLock` object. This makes
recursive locks as fast as regular non-recursive locks (previously,
they were slower by 10x to 15x).
svn+ssh://pythondev@svn.python.org/python/trunk
........
r76172 | antoine.pitrou | 2009-11-09 17:00:11 +0100 (lun., 09 nov. 2009) | 5 lines
Issue #7282: Fix a memory leak when an RLock was used in a thread other
than those started through `threading.Thread` (for example, using
`thread.start_new_thread()`.
........
svn+ssh://pythondev@svn.python.org/python/trunk
........
r76117 | antoine.pitrou | 2009-11-05 14:42:29 +0100 (jeu., 05 nov. 2009) | 5 lines
Issue #7264: Fix a possible deadlock when deallocating thread-local objects
which are part of a reference cycle.
........
Dong-hee Na
Skip Montanaro
Antoine Pitrou
Gregory P. Smith
Serhiy Storchaka
Xiang Zhang
Martin Panter
Zachary Ware
Benjamin Peterson
R David Murray
Victor Stinner
Antoine Pitrou
Raymond Hettinger
Tim Peters
Georg Brandl
Andrew Svetlov
Charles-François Natali
Ezio Melotti
Brett Cannon
Charles-François Natali
Éric Araujo
Victor Stinner
Gregory P. Smith
Kristján Valur Jónsson
Brett Cannon
Senthil Kumaran