Programming

You should not use old-style signal() handling together with sigprocmask(); the latter is part of a new set of functions that eclipse signal() entirely. sigaction() is the modern equivalent. It can be told to keep receiving a signal instead of needing to be reset every time. You shouldn't need to change the signal mask, I think, unless you need to block a signal, it should let them through by default.

I have removed the mask and switched to sigaction. The SIGINT problem still exists.

If I send SIGINT, then send SIGUSR1 and start using Python, it interrupts the Python instead of the C (even if I wait several seconds between sending SIGINT and SIGUSR1).

? Interrupts the pyton?

What command are you using to send the signal to the process? That it should kill the wrong one is quite bizzare.

I'm using the kill function (man 2 kill). I wrote a C function to grab the PID from test.RUN, write the action file, and send SIGUSR1. I call this from a separate Python process.

The Python interpreter is embedded in my executable. Maybe Python defines it's own signal handler for SIGINT (so it can print the traceback, etc.). But that would mean the signal is just sitting around until I call the Python interpreter.

Python definitely screws with signals to the bone for various purposes, one of which is to make sure signals are caught between opcodes instead of during them. It'd be better to have the signal handling done in python if you're going to use it.

But I only use Python for a small part of my program. I need SIGINT to work when I'm in the C part of my code also.