Item — HN Reader

If you misuse signals.

I am rusty on low level programming but I have done enough to know that this poster is whining a bit too much.

Signals should only be used in the general case for exceptional circumstances, like killing a programme. A signal handler's job is to deal with the crisis, e.g., gracefully exit.

In lower level cases signals mean there is an urgent event, something that must be done now or it is useless to bother.

If you try to use signals for general purpose IPC then you get what you deserve - chaos.

2 comments

As I mentioned in another comment, there are cases (like SIGWINCH) where the only interface the kernel gives you for general-purpose IPC is signals. In any case, if you restrict yourself to using signals for urgent respond-immediately events, then signalfd is still useless, since you want to handle those synchronously. :)

(That said, I would definitely agree that the kernel is misusing signals -- SIGWINCH should just be some form of metadata on the terminal fd, not a process-wide signal.)

This would probably be because by the time resizeable terminals became common, the semantics of the tty device were long settled. It probably would have made sense to create some kind of 'ttyaux' device at this point, though.

Except you're left with cases for which there is no alternative but signals (you name one; a sibling mentions WINCH, and I'll add SIGCHILD.), and for which the only reliable way to handle the case is to use the self-pipe trick, or maybe a signalfd.

It's not a case of "misuse": the API is so truly atrociously bad that any programmers attempt is going to be wrong. I'm aware of the pitfalls, and I do not feel comfortable stating that I would get it right; someone who is not aware of the pitfalls is hopelessly screwed.