[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20141208141039.GA4574@brightrain.aerifal.cx>
Date: Mon, 8 Dec 2014 09:10:39 -0500
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: [RFC] EINTR and PC loser-ing library design
On Mon, Dec 08, 2014 at 03:04:57PM +0100, dannym@...atchpost.org wrote:
> 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?
I don't see what problem you're trying to solve. EINTR does not happen
unless you intentionally request it by setting up an interrupting
signal handler, using sigaction() with the SA_RESTART flag clear. In
that case, you want the behavior, i.e. you want blocking functions to
fail when interrupted by the signal being handled.
Retry-on-EINTR loops are generally misguided unless they're in code
that's intended to be using in programs which use interrupting signal
handlers, but which need to reliably complete an operation even if
interrupted.
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
