User: Password:
|
|
Subscribe / Log in / New account

Signals vs. system calls

Signals vs. system calls

Posted Nov 16, 2010 20:43 UTC (Tue) by madscientist (subscriber, #16861)
Parent article: Ghosts of Unix past, part 3: Unfixable designs

Only lightly touched on here is the horrible-ness of signals interrupting system calls. The ability to set SA_RESTART is better than nothing but it has significant problems, in particular that it's not implemented appropriately everywhere (Linux is pretty good but Solaris, for example, is pretty bad).

This means that if, for example, you set a signal handler for SIGCHLD you have major problems since SA_RESTART can't be considered reliable (portably). The trick of having an internal pipe to communicate between your signal handler and your main event loop is still subject to this problem.

One assumes that signalfd() would not interrupt system calls on signals delivered through the FD so it solves that problem--but it's Linux-specific and Linux already handles SA_RESTART reliably.


(Log in to post comments)

Signals vs. system calls

Posted Nov 19, 2010 22:57 UTC (Fri) by giraffedata (subscriber, #1954) [Link]

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.

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.)


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds