hurd-devel
[Top][All Lists]
Advanced

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

Re: io_close proposal


From: Marcus Brinkmann
Subject: Re: io_close proposal
Date: Fri, 17 May 2002 02:38:51 +0200
User-agent: Mutt/1.3.28i

On Thu, May 16, 2002 at 05:30:06PM -0400, Roland McGrath wrote:
> Suppose a signal with SA_RESTART set is required to interrupt a close call
> so that it returns EINTR (e.g. breaking an SO_LINGER wait--but the system
> permitted to treat even an "instantaneous" close call as interrupted with
> EINTR) and then it's unspecified whether the fd is still open or not.  In
> that case, any application that might handle a signal while calling close
> must check for EINTR and repeat the close call, or else it may leak the
> descriptor in the event of a signal.  So, if that interpretation holds then
> a strictly conforming program that doesn't want to leak must do the loop or
> block signals around calling close or whatnot.  That seems like it would
> bite so many existing programs that I wonder if that could really be the
> intent.

At least it is documented this way in the GNU C library manual:

    `EINTR'
          The `close' call was interrupted by a signal.  *Note
          Interrupted Primitives::.  Here is an example of how to
          handle `EINTR' properly:

               TEMP_FAILURE_RETRY (close (desc));

Thanks,
Marcus

-- 
`Rhubarb is no Egyptian god.' Debian http://www.debian.org address@hidden
Marcus Brinkmann              GNU    http://www.gnu.org    address@hidden
address@hidden
http://www.marcus-brinkmann.de



reply via email to

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