In article <imqr00$5hb$1...@r03.glglgl.eu>, Thomas Rachel <nutznetz-0c1b6768-bfa9-48d5-a470-7603bd3aa...@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 (a...@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 -- http://mail.python.org/mailman/listinfo/python-list