Ok.. For my example.. I have a single program that manages
~40 other programs. One thing I would like to do is be able to set
a signal handler so that it would catch SIGCLD and then run
another instance of the program that quit. This is easy to do in
the C code, BUT I don't want to! I want it to be 100% changable
in Python code (thus more flexible). I COULD poll each process with
posix.kill(0,pid) but I really prefer NOT to have to poll..
This program will be doing enough keeping up with all the processing
it has to do on the side..
Another instance would be to catch SIGHUP so that you could monitor
a modem line and have Python code deal with a person hanging up on the
line..
>In any case you would have to handle them in a similar way as the
>KeyboardInterrupt exception is currently handled: the real (C) signal
>handler only sets a flag that the signal has arrived, and then later
>the interpreter checks this flag (possibly after each (virtual)
>instruction -- currently it's done only every few instructions) and
>invokes the code that handles the signal. I suppose you could set it
>up so that if the handler returns the interpreter continues where it
>left off, while if the handler raises an exception the interpreter
>passes the exception on. KeyboardInterrupt could then be made a
>special case of this.
This sounds reasonable.. I would be happy to code it.. (signal handling)
Where should I start looking?
>Note that you won't be able to catch program bugs in the Python
>interpreter this way (since they must be handled synchronously).
Not wanting to..
>There is also the problem that not all wrappers around blocking system
>calls (or blocking library calls) will will yield return when a signal
>handler is called, so the Python signal handling may wait until the
>call returns normally -- this is usually not what you want.
This should be ok in most cases.. at least the ones I am dealing with
Lance Ellinghouse
lance@markv.com