Re: io_close proposal

[Thomas Bushnell, BSG]

Well, I'm historically opposed, but I think the way you've specified
would help implement some important things (as you've noted).

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.)

Here are some problems.

First, we cannot obligate io users to call this function.  We can't
even say "it's a bug if you don't call it".  The only thing this call
does is synchronize certain actions that are coupled with last-close
in the servers.

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.

For example, consider this one:

* record locking: any close on a file descriptor (even a dup'ed one) should
  release all locks.

The last close should also cause this behavior, even if the last user
didn't bother calling io_close.  We cannot obligate the user to call
io_close if he doesn't want the close behavior, but the last-close
actions should happen whether or not the user calls io_close.  (I
understand that the record locking case is weird for a second reason,
that even non-last closes are supposed to have an effect.)

So the point is that closes on a pipe are supposed to have a special
semantic--not just close, but also, if this is the last close, then
wait for the server to record that fact before moving on.

Similarly for the SO_LINGER case.

These cases might be handled by a "I'm planning to close, so
synchronize" call--except that this would be wrong--the
synchronization should happen only if it is the *last* close, and the
server shouldn't even take the user's word for it that an impending
send right is being transferred.  So indeed, we do need to couple it
with sending the port.

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

Ok, but let's be *VERY* sure to say again and again that the user is
not somehow obligated to call it, ever.  A user is perfectly within
his rights to just deallocate ports if he doesn't care about the
synchronization or other close-time actions, and the server *MUST*
behave correctly--still doing the close-time actions, indeed, when
possible.  [In the case of record locks, it is not necessarily
possible.]

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.

Thomas