News for hackers. Stuff that matters.
Re:All about Linux signals - Linux Programming Blog by noselasd on Monday April 02, 2012 @04:05PM (#3789814)
I'd like some more around the "Interrupting system calls" section. This is a real can of worms. By default, signal() defaults to BSD semantics , which auto restarts syscalls, as do the SA_RESTART flag when the handler is established with sigaction(). Except not all calls are auto restarted, e.g. select/poll/sleep,

I'd really like to see a list of syscalls that are not restarted no matter the flags. And the macros that (implicitly) turn on SysV behavior of signal() ...

Re:All about Linux signals - Linux Programming Blog by antirez on Monday April 02, 2012 @05:19PM (#3790154)
Another thing that's not very clear from the document is: if the signal arrives in the course of a non-interruptible system call, when will it be delivered? As soon as the system call ends or anytime in the (near) future? Probably POSIX does not define this behavior, but it's useful for the programmer to know how most operating systems handle this.

Another interesting thing that I had to read in the Linux source code to be sure is that non-fatal signals can't interrupt a write(2) against the filesystem (and you can't have a short write count returned because of a signal). This is an assumption many programs rely on.

Re:All about Linux signals - Linux Programming Blog by calloc on Monday April 02, 2012 @05:19PM (#3790155)
The Linux man page on signals is surprisingly helpful in that regard: http://linux.die.net/man/7/signal