Antoine Pitrou added the comment: > It would be much nicer to have an approach that worked for all thread users, > not just threading.Thread users. For example, a user can easily (well, > plausibly) get into the same kinds of troubles here by calling > _thread.start_new_thread() directly, then waiting for their threads "to end" > before letting the program finish - they have no idea either when their > tstates are actually destroyed.
The _thread module is a private API these days, I wouldn't worry too much about that. Are there reasons *not* to use the threading module (except CPython bootstrap issues that normal users should have no bother about)? Also, how would they wait for the thread to end, except by triggering their own Event object? > So the new `waittime` _may_ be negative, in which case we've already timed > out (but passing a negative `waittime` to acquire() means "wait as long as > it takes to acquire the lock"). So this block should return if waittime < 0. Thanks, good point :-o As for the is_alive() method, mmh, ok, it needs to be tweaked too. That will make the patch more interesting. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue18808> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
