[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:52:16 +0100 |
User-agent: |
KMail/5.1.3 (Linux/4.4.0-112-generic; KDE/5.18.0; x86_64; ; ) |
Hi Eric,
> >> I think we'll need to fall back to a #if based on platforms.
> >
> > If I'm reading the POSIX bug correctly, HPUX is the only system where
> > fds are left open on EINTR.
Early Solaris is definitely in this camp as well.
> > Seems like a reasonable enough #if when
> > coupled with good comments pointing back to the POSIX discussion.
>
> One other possible alternative: instead of calling close(fd) on a random
> unknown fd, and worrying about the non-portability of EINTR behavior
> when that fd is something that takes a long time to close, you could use
> dup2()'s semantics to replace the original fd with something known to be
> safe to close (for example, closing an fd open on /dev/null doesn't have
> the risk of EINTR like you would have with closing an fd open on a pty
> or tape device).
This is an interesting, creative idea. However, because few people use this
'dup2 as a kind of atomic close' workaround, I fear that it might lead us
into the proximity of OS bugs. Hardly anyone has tested how dup2 works
in the presence of signals and ttys, in the past.
Bruno