Re: io_close proposal

[Marcus Brinkmann]

On Thu, May 16, 2002 at 12:08:27AM -0400, Roland McGrath wrote:
> I think any synchronization call definitely needs to be interruptible.

I think so as well, yes.

> If
> close can block, you should be able to take a signal during close and then
> resume it just like with other io calls.

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.

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.

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.

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.

> If you've lost the send right,
> then you don't have to wait for the reply but you can't restart the close
> operation.  If the RPC uses a move-send for the receiver right, then the
> only solution I see is special-case stubs on both sides so that the EINTR
> reply instead is a special format that returns the send right.  close will
> have to put that new right (which probably has a different name) into the
> dtable so that the fd can be used in the signal handler if the close didn't
> complete.

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.

Thanks,
Marcus