On Fri, Sep 06, 2002 at 05:09:16PM +0200, Jack Jansen wrote: > Could we connect signals to semaphores or locks or something > like that? That would allow you to do the two things that i > think are worth doing in a signal handler: setting a flag and/or > making some other part of the code wake up. Signal handlers and locks don't mix well. A signal handler can't grab a lock. The signal handler can't wait for the lock to be released because it has interrupted the code holding it. The traditional way this has been handled is with a global "interrupt enable" flag. Just like the good old days of 8 bit micros and DOS when any application could clear the interrupt flag :-) If Queue.Queue sets up a signal critical section as well as getting the queue lock a signal could write to a Queue and wake up a thread waiting on the other end. > Only problem is that for completeness you would really want to > wire up select-like functionality too, so that you could really > have a single waiting mechanism. If the program uses select as the central dispatcher you can set up a pipe. The signal handler writes to one end and the other end is listed in the select socket map. It's a simple way to handle an occasional event like a child process dying or a SIGHUP telling you to reload the configuration file. Do you want to use signals for more intensive tasks like asynchronous I/O? Oren
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4