| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
started once"
|
|
|
|
| |
instance stuck in initial state and present in threading.enumerate().
|
| |
|
|
|
|
|
| |
than those started through `threading.Thread` (for example, using
`thread.start_new_thread()`.
|
|
|
|
| |
which are part of a reference cycle.
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
Reviewer: Benjamin Peterson
|
|
|
|
| |
Reviewer: Christian Heimes
|
|
|
|
| |
they will still live in 3.0 but it can't hurt
|
| |
|
| |
|
|
|
|
| |
This is new in 2.6 so now need to worry about backwards compatibility :)
|
|
|
|
| |
-3.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
any given threading.Thread object. feature request issue 2871.
|
|
|
|
|
|
|
|
|
|
|
|
| |
sys.settrace
calls threading.currentThread.
The correction somewhat improves the code, but it was close.
Many thanks to the "with" construct, which turns python code into C calls.
I wonder if it is not better to sys.settrace(None) just after
running the __main__ module and before finalization.
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
Undo the only change that might have unexpected effects.
To be followed.
|
|
|
|
|
|
|
| |
up after it was joined had a traceback pointing to that thread's (deleted)
target attribute, while the test was trying to check that the target was
destroyed. Big thanks to Antoine Pitrou for diagnosing the race and pointing
out sys.exc_clear() to kill the exception early. This fixes issue 2496.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
new thread had started. At least on my MacBook Pro, that wound up sleeping for
a full 10ms (probably 1 jiffy). By using an Event instead, we can be absolutely
certain that the thread has started, and return more quickly (217us).
Before:
$ ./python.exe -m timeit -s 'from threading import Thread' 't = Thread(); t.start(); t.join()'
100 loops, best of 3: 10.3 msec per loop
$ ./python.exe -m timeit -s 'from threading import Thread; t = Thread()' 't.isAlive()'
1000000 loops, best of 3: 0.47 usec per loop
After:
$ ./python.exe -m timeit -s 'from threading import Thread' 't = Thread(); t.start(); t.join()'
1000 loops, best of 3: 217 usec per loop
$ ./python.exe -m timeit -s 'from threading import Thread; t = Thread()' 't.isAlive()'
1000000 loops, best of 3: 0.86 usec per loop
To be fair, the 10ms isn't CPU time, and other threads including the spawned
one get to run during it. There are also some slightly more complicated ways to
get back the .4us in isAlive() if we want.
|
|
|
|
| |
raises an exception.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
class RunSelfFunction(object):
def __init__(self):
self.thread = threading.Thread(target=self._run)
self.thread.start()
def _run(self):
pass
from creating a permanent cycle between the object and the thread by having the
Thread delete its references to the object when it completes.
As an example of the effect of this bug, paramiko.Transport inherits from
Thread to avoid it.
|
| |
|
|
|
|
|
| |
threading.enumerate() list after the join() for a brief period until
it actually exited.
|
| |
|
|
|
|
|
| |
to prevent spurious tracebacks when a daemon thread's cleanup happens to wake
up when the world around it has already been destroyed.
|
| |
|
|
|
|
| |
internal state, rather than assert statements (which get stripped out by -O).
|
|
|
|
|
| |
to avoid relying on atexit.
Will backport to 2.5.
|
|
|
|
|
|
|
|
|
|
| |
Heavily revised, comprising revisions:
46640 - original trunk revision (backed out in r46655)
46647 - markup fix (backed out in r46655)
46692:46918 merged from branch aimacintyre-sf1454481
branch tested on buildbots (Windows buildbots had problems
not related to these changes).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
46640 Patch #1454481: Make thread stack size runtime tunable.
46647 Markup fix
The first is causing many buildbots to fail test runs, and there
are multiple causes with seemingly no immediate prospects for
repairing them. See python-dev discussion.
Note that a branch can (and should) be created for resolving these
problems, like
svn copy svn+ssh://svn.python.org/python/trunk -r46640 svn+ssh://svn.python.org/python/branches/NEW_BRANCH
followed by merging rev 46647 to the new branch.
|
| |
|
|
|
|
|
|
|
|
| |
discussion.
There are two places of documentation that still mention __context__:
Doc/lib/libstdtypes.tex -- I wasn't quite sure how to rewrite that without
spending a whole lot of time thinking about it; and whatsnew, which Andrew
usually likes to change himself.
|
|
|
|
|
| |
this can just call __context__ on the underlying lock.
(The same change for Semaphore does *not* work!)
|
|
|
|
|
|
|
| |
Anyway, this is the changes to the with-statement
so that __exit__ must return a true value in order
for a pending exception to be ignored.
The PEP (343) is already updated.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- New semantics for __exit__() -- it must re-raise the exception
if type is not None; the with-statement itself doesn't do this.
(See the updated PEP for motivation.)
- Added context managers to:
- file
- thread.LockType
- threading.{Lock,RLock,Condition,Semaphore,BoundedSemaphore}
- decimal.Context
- Added contextlib.py, which defines @contextmanager, nested(), closing().
- Unit tests all around; bot no docs yet.
|
|
|
|
|
|
| |
exception (e.g., passing in an illegal argument).
Applies patch #1314396. Thanks Eric Blossom.
|
| |
|
|
|
|
| |
Closes bug #1110998. Thanks Matthew Bogosian.
|
|
|
|
|
|
|
|
| |
test_threading.test_foreign_thread(): new test does a basic check that
"foreign" threads can using the threading module, and that they create
a _DummyThread instance in at least one use case. This isn't a very
good test, since a thread created by thread.start_new_thread() isn't
particularly "foreign".
|
|
|
|
|
|
|
|
| |
_Thread.__init__) was never used. This is a waste since locks use OS
primitives that are in limited supply. So the lock is deleted in
_DummyThread.__init__ .
Closes bug #1089632.
|