Hacker News Reader

Comment by tuyiown | Hacker News Reader

I'm no UNIX guru but two things I've gathered:

1. For signal handling: if your signal handler needs to do more that setting a global value that ought to be read regularly by your program, consider that it might not be the mechanism you need, or that you're trying to hack around code design that have implications you really might not want to deal with.

2. For signal sending for process group control: read carefully manuals and forum helps to understand semantic subtleties between groups and sessions, as sending signals from a terminal with ctrl-<d,c,z,…> does not do the same thing than signaling processes from a program system call, which can really sway intuitions you might have on the subject.

(edit: fixed wrong example with ctrl-<…> signals)

View on HN

You can do surprising stuff in signal handlers; a program I used to work on had an interrupt menu in the signal handler. You could ctrl-c it and choose various "stop", "checkpoint", "dump status info" options. Similar to https://news.ycombinator.com/item?id=37899269 although without going quite so far as to adjust the stack with longjmp(). Whether you're "allowed" to do any of these things is another matter and they're almost certainly undefined behavior.

The interaction between threads and signals is really dire though. You need to mess around with signal masking. I think we'd ended up with an architecture where one thread caught the SIGINT and passed a SIGRT to a different thread; this behaved better in some way I cannot now remember.

If you want your program to be portable to Windows and MacOS as well, prepare for things to be differently broken there.

If your program has an async loop (select or poll etc.) then you need to know about the self-pipe trick for avoiding problems with signals. https://cr.yp.to/docs/selfpipe.html

The article explicitly mentioned signalfd, which is a less hackish way of doing the same.

signalfd() is less portable and has caveats around signal masks and subprocesses that you can avoid with the self-pipe trick.

> sending signals from a terminal with ctrl-<d,c,z,…>

Ctrl+D doesn't send a signal. It just causes the process that's reading from the terminal to get EOF.

ha yes sorry

This pattern of the signal handler merely setting a global var seems robust. Of course, now the programmer must decide when and where to check the global value.

It must also be of an atomic type. POSIX specifies exactly one, namely “volatile sig_atomic_t”. I guess in C++11 etc. you can also use the language-provided atomics.

Reply on news.ycombinator.com