Sure. Or just don't close() from a thread where you want to handle signals (without terminating, that is). Signals are the broken bits, frankly, not the POSIX standard. They have never played well with system calls. There's an essay somewhere I remember reading where an ITS hacker looks at Unix for how it handles the interrupted system call problem and comes away horrified at the discovery that it makes the user do it via EINTR.

There's no good reason to be catching synchronous signals in modern code[1]. See signalfd() et. al.

[1] Well, except for things that can only be delivered synchronously like SIGSEGV for user-handled paging. But that's complicated enough that the extra complexity of handling a SIGSEGV delivered out of a syscall is probably tolerable.

> There's an essay somewhere I remember reading where an ITS hacker looks at Unix for how it handles the interrupted system call problem and comes away horrified at the discovery that it makes the user do it via EINTR.

I think you're talking about Worse is Better: http://www.jwz.org/doc/worse-is-better.html

> There's no good reason to be catching synchronous signals in modern code

In libraries you can never know what the main program will do, and who wants to write a library that says "this library will malfunction if you use OS feature X"?

> See signalfd() et. al.

That's very cool, I had not seen that! But it's Linux-specific.

> There's an essay somewhere I remember reading where an ITS hacker looks at Unix for how it handles the interrupted system call problem and comes away horrified at the discovery that it makes the user do it via EINTR.

Not really the real point of the essay, but yeah there kind of is. Now come with a design (with similar premices, you can't just argue that the whole system call semantic has to change...) which does not involve the user, and we will talk.

Given that SA_RESTART already manages to perform that restart without the user's intervention, it is obviously pretty simple to come up with such a design: you just make SA_RESTART the default behavior. ;P

No reasons huh? I use signals to interrupt threads that block on open() and waitpid(). The only other alternative is sleep-polling which really sucks.

I said don't catch signals, not don't use them. See signalfd() et. al.

Though I'm curious why you're wanting to trying to interrupt those syscalls. In particular, why are you waiting on a process that you don't know is already dead? That's what SIGCHLD is for. And the only case I can think of for a blocking open() is a network/fuse mounted file. In which case the filesystem will surely eventually return an error (and if it doesn't no amount of voodoo in your application logic is going to correct the bugs in the underlying system).

signalfd() don't exist. I'm sorry that the manpage isn't really explicitly clear about that.

(It's a Linux-specific extension.)