threading.Semaphore (quite long)
aahz at pythoncraft.com
Tue Apr 12 18:06:04 CEST 2011
In article <imqr00$5hb$1 at r03.glglgl.eu>,
Thomas Rachel <nutznetz-0c1b6768-bfa9-48d5-a470-7603bd3aa915 at spamschutz.glglgl.de> wrote:
>I want to implement an alternative concept to worker threads processing
>a job queue. The alternative consists of threads being the jobs
>themselves and thus running only this one job. The job threads are
>started after a Semaphore's acquire() "giving the OK" to do so. The
>Semaphore's release() gets called inside the jobs/threads, saying
>"done, the next one please".
>But the program doesn't always stop on Ctrl-C.
>0. (First and in general) Am I doing "bad things" when calling release()
>at a completely different place than acquire() with a Semaphore? I used
>to believe that's why there are Semaphores?
Should be fine.
>1. Is a bug report useful, or would that worsen the problem, as the race
>condition doesn't disappear completely?
<shrug> If you can demonstrate that the problem occurs outside signals
(keyboard interrupt uses a signal), that would be more interesting
(signals and threads are often problematic).
>2. Is in, in general, an error to work with Semaphores (ore, more
>general with Locks) in the MainThread? Or should this be done in a
>separate thread being informed about a keyboard exception by the main
Outside of signals, there should not be a problem with that. I don't
have time to look further, I just noticed that nobody responded.
Aahz (aahz at pythoncraft.com) <*> http://www.pythoncraft.com/
"At Resolver we've found it useful to short-circuit any doubt and just
refer to comments in code as 'lies'. :-)"
--Michael Foord paraphrases Christian Muirhead on python-dev, 2009-03-22
More information about the Python-list