This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author tim.peters
Recipients Tamas.K, csernazs, grahamd, jcea, ncoghlan, neologix, pitrou, python-dev, tim.peters
Date 2013-09-06.00:19:24
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1378426766.78.0.328967780995.issue18808@psf.upfronthosting.co.za>
In-reply-to
Content
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 ;-)
History
Date User Action Args
2013-09-06 00:19:26tim.peterssetrecipients: + tim.peters, jcea, csernazs, ncoghlan, pitrou, grahamd, neologix, python-dev, Tamas.K
2013-09-06 00:19:26tim.peterssetmessageid: <1378426766.78.0.328967780995.issue18808@psf.upfronthosting.co.za>
2013-09-06 00:19:26tim.peterslinkissue18808 messages
2013-09-06 00:19:24tim.peterscreate