[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: spawn-pipe: close() EINTR handling
From: |
Pádraig Brady |
Subject: |
Re: spawn-pipe: close() EINTR handling |
Date: |
Wed, 03 Jul 2013 14:56:20 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130110 Thunderbird/17.0.2 |
On 07/03/2013 01:46 PM, Eric Blake wrote:
> 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.
OK maybe the gnulib code is safe because the close() is only done on pipes,
but I think the EINTR issue is definitely there with sockets.
For example see: http://alobbs.com/post/54503240599/close-and-eintr
thanks,
Pádraig.