interrupted close()

Hi,

I asked on the Austin Group list for clarification about the "unspecified"
in the documentation on close() when it is interrupted.  If close() is
interrupted by a signal, the standard says it should return EINTR and the
status of the filedescriptor is unspecified.

We wondered if that would mean that it must be in either of the two well
defined states still open and filedes is valid, or fully closed, including
the synchronization requirements met (like SO_LINGER or pipe end).

I received only a private response by Bruce Korb.  He wrote

> It means, "not specified".  It can be anything.  Retry the close.

The last sentence was obviously meant for the user side.

I asked back:

> Actually I am not asking from the user's perspective, but from the
> implementors.  If not specified can be anything, then that would be fine for
> us.

He replied:

> Then it is fine for you.  POSIX calls out "unspecified" whenever
> there is no clear "right" choice and it means implementors can
> do whatever is convenient.  Within that non-constraint, it is
> still best to do something that is as reasonable as possible
> within the implementors' operating environment.

I also asked:

> Can I quote you on our internal mailing list [email protected]?

He replied:

> Sure, but I am mostly a austin-group lurker.

There were no other replies (maybe there will be, I will keep you up to date).

To me this suggests the following:

We don't need to bother about having proper synchronization when close is
interrupted.  On the user side we can just invalidate the filedescriptor
(remove it from the fd table) and return EINTR.  On the server side, we
can just finish the close operation asynchronously in the normal way (eg,
let the no sender routine do the cleanup).

This should make io_close much simpler.  In particular, we don't need to
return the send right if it is interrupted.  We might still need a special
stub for it in glibc because the fd is invalidated and the stub should not
get an additional send right for the port argument.  Roland, how hard is it
to special case one RPC of a subsystem?  Or should we put it in a separate
subsystem (ugh).

Thanks,
Marcus

-- 
`Rhubarb is no Egyptian god.' GNU      http://www.gnu.org    [email protected]
Marcus Brinkmann              The Hurd http://www.gnu.org/software/hurd/
[email protected]
http://www.marcus-brinkmann.de/