In article <[EMAIL PROTECTED]>, "Yin" <[EMAIL PROTECTED]> wrote: > I am writing a script that monitors a child process. If the child > process dies on its own, then the parent continues on. If the child > process is still alive after a timeout period, the parent will kill the > child process. Enclosed is a snippet of the code I have written. For > some reason, unless I put in two time.sleep(4) commands in the parent, > the process will not sleep. Am I forgetting something? Any reasons > for this strange behavior?
... > signal.signal(signal.SIGCHLD, chldhandler) If you can possibly revise your design to avoid the need for this, by all means do so. The SIGCHLD signal interrupts functions like sleep(), and that's what you're seeing: the parent process didn't return to its sleep after handling the signal. What's worse, it affects other functions in a similar way, such as I/O. Try to read some input from the terminal, instead if sleeping, and you should crash with an EINTR error. Makes it harder to write a reliable program, when you're inviting such trouble. So far this is a low level UNIX issue that isn't peculiar to Python, but Python adds to the difficulties just in the general awkwardness of signal handling in an interpreted language, where handlers may execute somewhat later than you would expect from experience with lower level languages. And then if you decide to add threads to the mix, there are even more issues as signals may be delivered to one thread and handled in another, etc. If you're dispatching on I/O, for example with select, you can use an otherwise unused pipe to notice the child fork's exit -- close the parent's write end right away, and then when the pipe becomes readable it must be because it closed on child exit. Donn Cave, [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list