[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Retrying close() after error on Linux !?

From: Bruno Haible
Subject: Re: Retrying close() after error on Linux !?
Date: Wed, 14 Mar 2018 18:09:34 +0100
User-agent: KMail/5.1.3 (Linux/4.4.0-112-generic; KDE/5.18.0; x86_64; ; )

Hi Eric,

> > just stumbled upon nonintr_close() in spawn-pipe.c which has this loop:
> > 
> >    do
> >      retval = close (fd);
> >    while (retval < 0 && errno == EINTR);
> > 
> > 
> > Regarding the man page of libc, this shouldn't be done on certain
> > systems. E.g. it says the Linux kernel closes the file descriptor even
> > on EINTR. With the effect of possible race conditions in multi-threaded
> > code.
> > 
> > 
> > What do the experts here say ?
> Here's what POSIX has to say:
> http://austingroupbugs.net/view.php?id=529#c1200

Glad to see that this has been addressed in POSIX.

I definitely saw the need to handle EINTR with various system calls (read,
write, close) on early versions of Solaris, when a signal handler for SIGINT
is installed and the user presses Ctrl-C.

The types of fd on which this occurred were likely ttys and possibly NFS
mounted files (don't remember exactly).

> It is better to leak the fd (on the few implementations that 
> leave fd open on EINTR failure) than to risk corrupting multithreaded 
> state.

No, not in all situations. When fd is a tty and you spawn a process that
is intended to communicate through a pipe, the usual end-of-stream handling
(EOF for reading, SIGPIPE for writing) will NOT happen if there is an fd
that has accidentally been left open. Therefore in spawn_pipe it is essential
that close() really closes what was intended.

I think we'll need to fall back to a #if based on platforms.


reply via email to

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