threading.Semaphore (quite long)

[Aahz]

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 
>thread?

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