From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/6686 Path: news.gmane.org!not-for-mail From: dannym@scratchpost.org Newsgroups: gmane.linux.lib.musl.general Subject: [RFC] EINTR and PC loser-ing library design Date: Mon, 08 Dec 2014 15:04:57 +0100 Message-ID: References: Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Trace: ger.gmane.org 1418047525 27674 80.91.229.3 (8 Dec 2014 14:05:25 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 8 Dec 2014 14:05:25 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-6699-gllmg-musl=m.gmane.org@lists.openwall.com Mon Dec 08 15:05:19 2014 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1Xxyw9-00025f-By for gllmg-musl@m.gmane.org; Mon, 08 Dec 2014 15:05:17 +0100 Original-Received: (qmail 3424 invoked by uid 550); 8 Dec 2014 14:05:15 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 3416 invoked from network); 8 Dec 2014 14:05:14 -0000 User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.8 EasyPG/1.0.0 Emacs/23.4 (arm-unknown-linux-gnueabihf) MULE/6.0 (HANACHIRUSATO) Xref: news.gmane.org gmane.linux.lib.musl.general:6686 Archived-At: 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 . 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