[RFC] EINTR and PC loser-ing library design

[dannym@scratchpost.org]

Hello,

I just had another hunt for bugs through libraries for EINTR-related woes.
I thought before I patch them, I'd make a proposal here.

EINTR is an ancient wart and like anyone else I have learned to live with it. 
But over the years it has never stopped bothering me. 
And this series of EINTR bugs made me lose confidence that the current way is sustainable.

EINTR serves two purposes:
1) makes the kernel easier by it not having to remember kernel-internal state of a running syscall when a signal arrives.
2) allows the user to see immediately when signals arrive - without having to do unsafe things in the signal handler.

Unfortunately, many routines retry on EINTR without thinking about 2).
Many non-libc routines don't even retry, breaking 1).
So 2) is unusable in practise, even though it's the only sane justification for EINTR to be there in the first place.

What I propose is the following:
- add an intr_handler callback (pointer) to libc, setable by the user, defaulting to one just returning (-1).
- adapt the syscall() interface (~50 system call wrappers of system calls that can return EINTR) to:
    on EINTR, call the callback, and retry the interruptible call only if the callback returned 0.
- adapt TEMP_FAILURE_RETRY(x) to do that as well, for forward compatibility.

The callback is supposed to be provided by the user and supposed to check some flags it set in the signal handler.
Once the callback returns (-1), it shall keep returning (-1) until something is reset by the user manually.

That way, both 1) and 2) work.

Backwards compatibility is ensured since the default callback will cause the syscall wrapper to do the same it always did.
But new programs could now not worry about EINTR except if they wanted to.

I put (way) more detail on <http://www.scratchpost.org/software/%3Carticle%3E/EINTR/>.

What do you think? Do we even want to change this to do the right thing?

If yes, I'd we willing to do the work needed.

If no, can we add just the callback pointer so we have a common interface for everyone else to call?

Thanks,
   Danny