[Top][All Lists]

[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

Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]