From mboxrd@z Thu Jan 1 00:00:00 1970 From: Danny Milosavljevic Subject: Re: System calls interrupted by signals - or not Date: Thu, 1 Feb 2018 10:33:34 +0100 Message-ID: <20180201103334.5a803d2d@scratchpost.org> References: <20180129122403.22184.83539@vcs0.savannah.gnu.org> <20180129122403.D1E1420ABC@vcs0.savannah.gnu.org> <87efm8ojpc.fsf@gnu.org> <20180129150249.7a1a7140@scratchpost.org> <87bmhcbu3e.fsf@netris.org> <20180131003529.03312495@scratchpost.org> <878tcewzbx.fsf@netris.org> <20180201010153.0c6146f0@scratchpost.org> <877erxunyq.fsf@netris.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:57664) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ehBFZ-00087k-EP for guix-devel@gnu.org; Thu, 01 Feb 2018 04:33:51 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ehBFW-0000Ph-BU for guix-devel@gnu.org; Thu, 01 Feb 2018 04:33:45 -0500 Received: from dd26836.kasserver.com ([85.13.145.193]:33044) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1ehBFV-0000OO-VY for guix-devel@gnu.org; Thu, 01 Feb 2018 04:33:42 -0500 In-Reply-To: <877erxunyq.fsf@netris.org> List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: Mark H Weaver Cc: guix-devel@gnu.org Hi Mark, On Thu, 01 Feb 2018 03:13:33 -0500 Mark H Weaver wrote: > Guile is a library meant for use within existing applications, and > therefore needs to be able to cope with whatever signal handling policy > those applications have chosen. We certainly cannot assume that all > kinds of signals will be configured for SA_RESTART. That's too bad. It can't be helped, then. Then see the table for a little overview. (I've tried very hard to sensibly handle EINTR in the past and it's surprisingly difficult - that table is what I got out of it - and the decision to avoid PC-losering signals whenever I can) And even for the purported use of EINTR (so that you can have complicated signal-unsafe handler actions after an "if (errno =3D=3D EINTR)" block) it's difficult to get right. That's because you only get EINTR when a syst= em call has been interrupted by a signal. It can happen that you aren't yet in the system call, the signal handler runs (to completion), and then you ente= r a system call. You *don't* get EINTR for the missed signal then. I don't know what they were thinking. > There are cases where you may want the > ability to interrupt a system call without killing the thread. Suppose > you are waiting for a large I/O operation to complete over a slow > network or device. Signals are the only way I know of in POSIX to > interrupt a system call, but it can only be done if there's at least one > kind of signal that's not configured for SA_RESTART. That's a good point. But many people just use do { syscall } while (errno =3D=3D EINTR); in random libraries and then you can't interrupt the system call after all in your user program. Also, there's a race because you can be right before entering a system call, your signal handler runs, and then the system call isn't interrupted after all (because there was nothing to interrupt - and now you can't branch on it anymore. That's how I started to enter this EINTR rabbit hole - one of my programs had such a bug). > "When you don=E2=80=99t specify with =E2=80=98sigaction=E2=80=99 or =E2= =80=98siginterrupt=E2=80=99 what a > particular handler should do, it uses a default choice. The default > choice in the GNU C Library is to make primitives fail with =E2=80=98E= INTR=E2=80=99." :-(