[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: spawn-pipe: close() EINTR handling
From: |
Eric Blake |
Subject: |
Re: spawn-pipe: close() EINTR handling |
Date: |
Wed, 03 Jul 2013 06:46:29 -0600 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7 |
On 07/03/2013 05:26 AM, Pádraig Brady wrote:
> So I was reading http://austingroupbugs.net/view.php?id=529
> which states on Linux that one shouldn't retry close() after EINTR
> as the descriptor is already closed in that case
> and another thread could reuse the descriptor
> which a retried close() would close erroneously.
If Linux ever returns EINTR on close(), that's a bug in Linux. While
researching the resolution to
http://austingroupbugs.net/view.php?id=529, I asked Linux kernel
developers if EINTR is even possible, and no one could point to a
definitive code path with an EINTR.
>
> That suggests that the following code in spawn-pipe is problematic?
> Should be remove the retry, and/or do we need to otherwise
> handle the SIGSTOP case?
>
> thanks,
> Pádraig.
>
> /* EINTR handling for close().
> These functions can return -1/EINTR even though we don't have any
> signal handlers set up, namely when we get interrupted via SIGSTOP. */
That may be a true statement for OS's that return EINTR on close
failure, but my understanding Linux is not such a platform. All known
platforms that have EINTR failure (basically HPUX) also leave the fd open.
>
> static int
> nonintr_close (int fd)
> {
> int retval;
>
> do
> retval = close (fd);
> while (retval < 0 && errno == EINTR);
>
> return retval;
> }
> #define close nonintr_close
>
My assumption is that the gnulib code is safe as-is, because the EINTR
check is dead code on Linux.
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature