Tim Peters added the comment:
So you're not concerned about a now-private API (which used to be advertised),
but are concerned about a user mucking with a new private lock in an
exceedingly unlikely (in the absence of malice) way. That clarifies things ;-)
I'm not really concerned about either. User perversity knows no limits,
though, so I wouldn't be surprised if some people are rolling their own
higher-level threads in Python for reasons they think are compelling.
Details don't really matter to that, right? Like:
> Also, how would they wait for the thread to end, except by
> triggering their own Event object?
Any number of ways. Roll their own Event, roll their own Barrier, roll their
own Condition, or even something as simple as keeping an integer count of the
number of threads they created, and then (e.g.)
while nthreads:
time.sleep(1)
at the end, with each thread doing a
global nthreads
with nthreads_lock:
nthreads -= 1
in its end-of-life code. Essentially rolling their own clumsy variant of a
Semaphore.
I've seen code like that "in the wild". But, no, I'll join you in not worrying
about it ;-)
----------
_______________________________________
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
