Re: io_close proposal

[Roland McGrath]

> I am not sure I agree with this.  POSIX says that if the program
> receives a signal during close(), close() should return with -1 and
> errno set to EINTR, and the state of the filedescriptor that was about
> to be closed is undefined.

Well, how about that.  But actually it says "unspecified", which is
different.  (I'm looking at POSIX.1-1996.)  I'm not exactly sure what
latitude we have here.  That is, options that are semantically different
from either as if no close call was made or as if close completed normally.

> To me that seems like we can just attempt io_close() once, and when we
> are interrupted, destroy the reply port and return to the user.

Probably so.

> I also don't think we need to interrupt the pending io_close() operation
> in the server, we can just let the server finish the io_close() and send
> the reply to the (now or soon) invalid reply port.  For extra kindness,
> we can interrupt the pending operation, though.

It never makes sense to interrupt if you don't care to synchronize.  If you
were SIGKILL'd you wouldn't send the interrupt to any servers, so they have
to be prepared to cope.  If the synchronization blocks can ever take very
long, then the server might want to interrupt_self_on_port_death.

> I hope I don't misunderstand what restarting an RPC means here, but I
> guess we are talking about SA_RESTART handling in glibc/hurd/intr-msg.c
> and such alike.

Right.  Without worrying about the actual implementation details, you can
think of it as being that the io_foobar call is made anew after the signal
handler runs.

> The way I read POSIX, we are not even allowed to restart the operation,
> but we must (POSIX says "shall") return -1/EINTR.  But I only checked
> the definition of close() so far, not if SA_RESTART overrides this.

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.