On Feb 15, 1:28 pm, Dan Stromberg <drsali...@gmail.com> wrote: > *ix signals have historically been rather unreliable and troublesome > when used heavily. > > There are BSD signals, SysV signals, and POSIX signals - they all try > to solve the problems in different ways.
No, there are just signals[1]. There are several different APIs for handling signals, depending on the situation, but they're all driving the same functionality underneath the covers. These days, only sigaction(2) is remotely usable (in C) for installing handlers and all the other APIs should normally be ignored. > You might also make sure your SIGCHLD signal handler is not just > waitpid'ing once per invocation, but rather doing a nonblocking > waitpid in a loop until no process is found, in case signals are lost > (especially if/when signals occur during signal handler processing). This is the most likely the issue. Multiple instances of the same pending signals are coalesced together automatically. It would also help to make sure the signal handler just sets a flag, within the application's main loop it should then respond to that flag appropriately. Running anything inside a signal handler is a recipe for disaster. Also, SIGCHLD handlers may not get reinstalled on some operating systems (even in Python), so the application code needs to reinstall it. If not done within the signal handler, this can caused signals to get "lost". That being said, I'd just spawn a thread and wait there and avoid SIGCHLD altogether. It's typically not worth the hassle. > Oh, also, signals in CPython will tend to cause system calls to return > without completing, and giving an EINTR in errno, and not all CPython > modules will understand what to do with that. :( Sadly, many > application programmers tend to ignore the EINTR possibility. This can be disabled by signal.siginterrupt(). Regardless, the signal handling facilities provided by Python are rather poor. Adam [1] Ok, I lied, there's regular signals and realtime signals, which have a few minor differences. -- http://mail.python.org/mailman/listinfo/python-list