Message197177
| Author |
tim.peters |
| Recipients |
Tamas.K, csernazs, grahamd, jcea, ncoghlan, neologix, pitrou, python-dev, tim.peters |
| Date |
2013年09月07日.18:32:00 |
| SpamBayes Score |
-1.0 |
| Marked as misclassified |
Yes |
| Message-id |
<1378578720.98.0.225343898764.issue18808@psf.upfronthosting.co.za> |
| In-reply-to |
| Content |
New patch threadstate_join_5.patch adds more testing of is_alive().
An inelegance I don't care about (but someone might): if join() is called with a timeout, and the Python part of the thread ends before the timeout expires (_stopped gets set), then a _non_-blocking attempt to acquire _tstate_lock is made, and join() returns regardless of the outcome. So, with a timeout, it's possible for join() to return before the C part of the thread is done even if the timeout isn't yet exhausted.
That's unlikely, and I don't see that it makes any difference. Anyone doing a join() with a timeout has to be aware that they have no idea whether the thread is done when join() returns, and do another join() or check is_alive() later.
I'd rather not complicate the code to wait longer for _tstate_lock in this case. |
|