Re: io_close proposal

[Roland McGrath]

Actually, isn't there a race in libports if we use a move-send right for
the receiver port?  The last send right will move into the message and then
won't a no-senders notification be generated while the message is queued?
That is, the no-senders might arrive before the io_close is dequeued and
libports gets a ref on the object.  In that case, the object has already
been destroyed and certain kinds of synchronization might no longer be
possible (e.g. SO_LINGER).  The server could do appropriate synchronization
via seqnos if the no-senders is actually after the message and not before,
i.e. the io_close gets seqno N and the no-senders gets seqno N+1.  I would
have to read the IPC code to try to know if that's so.  It would be an easy
enough experiment though, with just a mach_msg_send using move-send for the
target port in one task and receiving on the receive right in another task
to display the seqnos and message-ids.

If it turns out that the no-senders arrives before the RPC, then this plan
won't fly and we will have to send a normal RPC first and then deallocate
second.  It will take some thought to implement that on the server side.