Re: io_close proposal

[Thomas Bushnell, BSG]

Roland McGrath <address@hidden> writes:

> I think you are probably right about this.  The question is whether, if the
> appropriate synchronization has not happened, we are required to leave the
> descriptor open (as if close had never been called).  Depending on exactly
> what "unspecified" means here, an application might be justified in
> diagnosing the EINTR failure and then using the descriptor again (perhaps
> in calls other than just retrying the close) and expect either EBADF with
> an implied guarantee of appropriate synchronization e.g. with the other end
> of the pipe, or behavior exactly as if the close call had never been made,
> and nothing in between.

I think it's clear we can have a half-sane state--that is, we don't
have to choose between "no close at all" and "completely executed
close".

A sample on-close semantic for some network protocol might require a
two-way handshake with some remote host.  You send your half, and then
block until the other side sends their thing.  If this gets
interrupted, you can't guarantee that the handshake has completed
(that's what you're waiting for) and you also can't back it out, since
the remote side might have torn down arbitrary state already.

Since this is true for Unix too, it seems to me we are justified in
being arbitrarily broken on an interrupted close.  Of course, we
should try to be as little broken as sanely possible.