I am thinking on a way of communication between signal handlers and the main program. Note, I use mosly non-blocking signals (a new signal can arrive even while a signal handler is executed), so I am looking for a lock-free solution.

My current idea is this:

  1. Creating a socketpair(...) yet before the signal handler is installed (with sigaction(...)).
  2. The signal handler sends everything what I need to do, into a file descriptor of this socketpair.
  3. The main process polls the incoming data from the other file descriptor, and processes is as it is needed.

Of course I plan to set up a quite high internal buffer size (with setSockOptInt(SOL_SOCKET, SO_SNDBUF, size);), and correctly terminate the program on an overflow (send(...) in the signal handler returns some... unfeasible.

I think, possibly it might violate some Posix.* standards, because they restrict the signal-safe libc functions quite strongly. However, writing into sockets is, as far I know atomic (I am nearly 100% sure that it is the case if I use send() to datagram sockets).

Is it correct? Could it work?


For a list of the functions that are safe in signal context, take a look at man 7 signal-safety. From that page:

The  set  of  functions  required to be async-signal-safe by POSIX.1 is
shown in the following table.  The functions not otherwise  noted  were
required  to  be  async-signal-safe  in POSIX.1-2001; the table details
changes in the subsequent standards.

Function               Notes

So, using send() or write() on the file descriptor associated with your socket (or any file descriptor for that matter) is signal-safe.

| improve this answer | |
  • I'd also recommend setting the file descriptor to non-blocking in order to eliminate the possibility of a deadlocked process. – Andrew Henle Jul 8 at 13:59

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.