Python generally has a great interface to Unix; through various modules(not just os , but also things like socket , select , and so on) itexposes almost all of the generally useful APIs and does so in a waythat is simultaneously Unixy and Pythonic. The best way of putting itis that everything just works, and just works the way you'd expect itto if you know the C-level API and Python.

(This is one reason that I have never been terribly energized aboutthe ctypes

CPython handles Unix signals somewhat oddly, or at least not in what youmight think of as a standard Unix way. I've covered part of this beforein SignalProblem and made side mentions in other entries, but I want towrite all of this down in one place (even if only as an index).

First, none of this applies if you set a signal's handler to SIG_IGN or SIG_DFL . Those get standard Unix semantics, because CPython justsets the signal to either of

In brief, the Python SIGCHLD problem is that while C-level SIGCHLD signal handlers are protected against reentrancy, your Python level SIGCHLD handler function is not, because it is not actually executedas a C-level signal handler. This winds up causing heartburn andpotential explosions if you do anything sophisticated when childprocesses exit. (See SIGCHLDVsPython for a longer discussion.)

In thinking about the problem, I've realized that signal.signal() is itself a peculiar but useful atomic operation. This is important,