From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16260 invoked by alias); 7 Oct 2016 14:50:58 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 16238 invoked by uid 89); 7 Oct 2016 14:50:57 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=0.6 required=5.0 tests=AWL,BAYES_50,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=Doctor, interrupted, continuously, forever X-Spam-User: qpsmtpd, 2 recipients X-HELO: mail-oi0-f65.google.com Received: from mail-oi0-f65.google.com (HELO mail-oi0-f65.google.com) (209.85.218.65) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 07 Oct 2016 14:50:46 +0000 Received: by mail-oi0-f65.google.com with SMTP id d132so3499364oib.2; Fri, 07 Oct 2016 07:50:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=g/mt+ScIioGEThOIOxU0P0mvsPuNhlI+y4cqOqJpdXc=; b=UBB1y+LbXk1uN4dIJx6507yoR8FvCjAaU8g28lBlsDu+GGofis6rF3rK+YxwkoYEyD NEe0/W2UHVxBNgtx8P0KIvjP022UwXPNsUpULwvP60O19wDE036WVdABB6GX/my9ML7Z Xm6b1FY+VDolSx3U+SNpx3MQHqOKaiLycQI64yYtjjb3aL+E2aygtoav9w2rwyhIXWc+ opW/JEwoRcfHiqX+kVY3+l0IODHaYPbslxvRPHQUxSY5u4dy1IPBVdjcI8w7IlxM4oo1 0bnNVoLxc8NO7gMLFkVxqzLL2yeFV3ZgnSr0Dp1KgkfNmWa+4r26aacz+GYX/xP68C65 NQUQ== X-Gm-Message-State: AA6/9RnXuaqL0ogY+iVRSFvYRT5cFgRJUpI/cd/zJMgzqveDr7AIbKmnp3D87XK9ePaa7D6Dj4iCYxx6SmIEuw== X-Received: by 10.202.214.69 with SMTP id n66mr16666869oig.82.1475851845197; Fri, 07 Oct 2016 07:50:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.80.166 with HTTP; Fri, 7 Oct 2016 07:50:44 -0700 (PDT) In-Reply-To: References: <1475843186-3429-1-git-send-email-blomqvist.janne@gmail.com> From: Fritz Reese Date: Fri, 07 Oct 2016 14:50:00 -0000 Message-ID: Subject: Re: [PATCH, libgfortran] PR 67585 Handle EINTR To: Janne Blomqvist Cc: FX , Fortran List , GCC Patches Content-Type: text/plain; charset=UTF-8 X-SW-Source: 2016-10/txt/msg00494.txt.bz2 On Fri, Oct 7, 2016 at 8:59 AM, Janne Blomqvist wrote: > On Fri, Oct 7, 2016 at 2:41 PM, FX wrote: >>> Many POSIX systems have the bad habit of not restarting interrupted >>> syscalls. On these systems it's up to the user to check for an error >>> with errno == EINTR and restart manually. This patch does this for >>> libgfortran, so that GFortran users don't have to do it. >> >> I have not much experience with EINTR, but is it garanteed that those EINTR loops will never cycle forever? > > Hmm, no I don't think so, but I don't think it'll be a problem. So on > systems where syscalls are not restarted automatically, EINTR happens > when the process receives a signal while blocked in a system call [1]. > So I suppose in theory you could have a situation where something > continuously fires signals at the process, and the result is some kind > of race between the process restarting the syscall which then never > manages to complete before being interrupted again. But I think this > goes into the "Doctor, this hurts! Then don't do that" territory. > > There's some more info in https://www.python.org/dev/peps/pep-0475/ > (Python nowadays does the same as this patch). Just one concern (slightly different from the race you described) - what if a user wants/expects a system call to be interrupted? With the patch we would always restart the system call even if the user was expecting it would be interrupted. For small calls like lseek this may not be a big deal but if read on a pipe/socket/terminal is restarted after being interrupted (e.g. with CTRL-C) we may loop forever even if the user program was written to expect and handle EINTR after the read call, e.g. to terminate nicely with "non async-safe" calls like printf that couldn't be done in the handler. This is discussed as "use case 2" in the PEP you referenced. Python handles this case by explicitly calling user defined signal handlers directly after EINTR and checking the return value from the handler, only trying again if the handler reports success. Not so simple I think with libgfortran. --- Fritz Reese