Re: io_close proposal

[Marcus Brinkmann]

On Wed, May 15, 2002 at 05:27:58PM -0700, Thomas Bushnell, BSG wrote:
> Roland is right that you should just drop the argument and make the
> receiver a mach_port_poly_t thing.  (You'll have to make sure the same
> INTRAN function gets used though, of course.)

Ok.

> Here are some problems.
> 
> First, we cannot obligate io users to call this function. 

Agreed.  There is no need, the server couldn't care less about the
user's need for synchronization.  All things important to the server
end up in the handling of no-senders notifications as before.

In addition, the no-senders notification might trigger a blocking
io_close() to return (for example, I am not 100% sure on how to
structure this best).

> The samples you give are all cases where close turns out to require
> synchronization.  While I think it sucks, it is the way of Posix, and
> we've just got to do the best we can.

In particular, the way record locks work is horribly inconsistent with
all the rest.  A blocking close() is not really unreasonable in my eyes.

> That means that I think Marcus is right, we need this call.

Just for completeness, I have considered other ideas where the user
requests last-close notifications from the server, and it doesn't work
out.  Only the server can tell if the user should block now, and he
can only do this if the user helps him by giving up the send right.

Another idea: The actual number of extinct send rights (instead just a
boolean) could be helpful.  If the server would get the exact number, and
it would be 1 (assuming the user does not transfer the send right),
he would know that the send right used to send the message was the only
one, and he could just go forward and destroy the port.
But I don't think this solution (if it is one) is very elegant.

> Second worry.  Programs calling exit shouldn't have to wait for
> possibly malicious servers to respond to io_close.  But the same
> synchronization issues happen for close-on-exit.  This is more
> serious, and I'd like to hear some thinking about it before we make
> this (rather significant) interface change.
> 

I wonder if we are really interested in doing the close()
synchronization on exit.  The only case where this possibly means
something is SO_LINGER, where it would delay the actual exit until the
timeout happens.  A pipe close is only interesting if another program
expects the pipe close to happen before the task exits, I guess this is
a bit weird thing to do [although perfectly within POSIX guarantees, it
seems], and record locks, well, they have to be removed with process
death anyway.

But I am willing to put more thought into that.  I definitely don't want
to rush this interface.  I posted this to hear about such problems,
so I learn what we have to consider, and try to find solutions to them.

Thanks,
Marcus