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.
Copyright © 2018, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds