
All about Linux signals (2009) - ingve
http://www.linuxprogrammingblog.com/all-about-linux-signals?page=show
======
geocar
I don't think enough time is spent on signalfd: It's not just great if you
have it, it's easy to emulate if you don't[1], so it's worth designing
programs to use it instead of trying to handle interrupted system calls
everywhere.

SIGIO could have gotten more attention, it get's a poor treatment because
epoll/kqueue are better, but if you stop thinking about getting out of the
signal handler as fast as possible and start thinking of it as a kernel-side
queue you can save a couple syscalls on an IO-heavy application.

There's some neat tricks you can do with SIGURG as well, since it lets remote
processes(!) send a signal ahead of the TCP buffer.

Another good thing worth mentioning is the trick of trapping SIGSEGV/SIGBUS to
sbrk; something like this:

    
    
        char*p=sbrk(0);
        void h(int _){ sbrk(4096);signal(SIGSEGV,h); }
        signal(SIGSEGV,h);
    

This allows you to manually manage memory without having to check how close
you are to the end of memory[2] which can really simplify some programs, since
you'll get a hardware trap that automatically extends the data segment when
you write off the end of memory.

SIGXFSZ can be dealt with similarly: So many programs try to track bytes
copied (quotes, etc) when setrlimit and a signal is easier. More programs
don't bother which is annoying.

Also not mentioned: The terminal. SIGWINCH[3] which is useful for getting
updated when the window resizes, and SIGTSTP/SIGCONT is how you detect a
console user putting you in the background.

[1]:
[https://cr.yp.to/docs/selfpipe.html](https://cr.yp.to/docs/selfpipe.html)

[2]:
[https://github.com/geocar/ed-v6/blob/master/ed.c.orig#L608](https://github.com/geocar/ed-v6/blob/master/ed.c.orig#L608)

[3]:
[http://web.mit.edu/~mkgray/jik/sipbsrc/src/utree/tst/sigwinc...](http://web.mit.edu/~mkgray/jik/sipbsrc/src/utree/tst/sigwinch.c)

~~~
to3m
The self-pipe trick isn't a perfect replacement for signalfd, because the
signals aren't blocked. Blocked signals don't cause EINTR when they're
received.

When working on OS X (and presumably BSD), you can use kqueue (the OS X man
page is comprehensive) to watch for signal delivery. The same SIG_BLOCK
requirement applies.

(Whether this is a practical matter, on the other hand, I'm not sure... if
your main loop is based around select/poll/kqueue/etc., you probably won't be
making any calls that would block anyway. And I'm not even sure that avoiding
EINTR is such a great idea in the first place, though obviously if you have to
block it to use signalfd/kqueue then you must. But it's actually quite a
useful error to receive, and fits in quite neatly with level-triggered
polling.)

~~~
geocar
They do if you use SA_RESTART :)

~~~
to3m
That's a good point! I forgot about SA_RESTART.

------
justincormack
Since this came out memfd(2) was created to stop the segfault on truncated
mmap file issue, you can seal memmapped regions so they cannot be resized.

------
teddyh
See also _Proper handling of SIGINT /SIGQUIT_
([http://www.cons.org/cracauer/sigint.html](http://www.cons.org/cracauer/sigint.html)).

