Signals vs. system calls [LWN.net]

Signals vs. system calls

Posted Nov 19, 2010 22:57 UTC (Fri) by giraffedata (subscriber, #1954)
In reply to: Signals vs. system calls by madscientist
Parent article: Ghosts of Unix past, part 3: Unfixable designs

I can't quite tell what problem you're pointing out. Are you saying it's horrible that anything that makes a system call of an interruptible type has to check for EINTR or partial completion and repeat/resume the system call?

Of course, any solution in which system calls are uninterruptible defeats half the purpose of a signal.

The trick of having an internal pipe to communicate between your signal handler and your main event loop is still subject to this problem.

I'm familiar with the trick of having such an internal pipe -- it solves the problem of select() not getting interrupted when a signal arrives just as select() is starting. But I don't see the connection between that and horribleness of signals interrupting system calls.

One assumes that signalfd() would not interrupt system calls on signals delivered through the FD

signalfd() just generates the file descriptor, so of course it doesn't interrupt anything. If you mean that in a program that uses signalfd(), system calls don't get interrupted, I think you're right because a program that uses signalfd() normally blocks signals, and a blocked signal can't interrupt a system call. But that just means that a program that uses signalfd() can't fully exploit signals -- control-C won't unhang some things.

(Log in to post comments)

Signals vs. system calls

Posted Nov 25, 2010 5:55 UTC (Thu) by rqosa (subscriber, #24136) [Link]

> But that just means that a program that uses signalfd() can't fully exploit signals -- control-C won't unhang some things.

The solution to that is to use non-blocking system calls (or at least ones that you know will only block for a short time). That's something that you should already be doing if you're using signalfd(); the purpose of signalfd() is to handle signals with an event loop, and an event loop shouldn't have any blocking system calls in it (or anything else that takes a long time) except for the one select() (or epoll_wait() or similar) that drives the event loop.

(If there's some type of event whose handler must take a long time to run, then have the event loop hand it off to a worker thread/process.)