Re: behavior of NO SENDERS notifications when receive rights move

[Kalle Olavi Niemitalo]

"Brent W. Baccala" <cosine@freesoft.org> writes:

> Now I'm wondering - how would DEAD NAME notifications be handled?  rpctrace
> would want to transfer send rights with the DN notifications attached (so
> it could wrap them both), but my experience, and my understanding of the
> Mach documentation, is that moving a send right with a DN request triggers
> a PORT DELETED notification, which is not what we would want.

Before rpctrace moves the send right from the target task, it
could call mach_port_request_notification to cancel the dead-name
notification request.  This call returns the send-once right to
which the notification would have been sent.  After rpctrace has
moved the rights, it could restore the notification request,
now with a wrapped send right and a wrapped send-once right.

> We could swap the ports all around with the target
> task halted, and I'm not sure what would happen then.

Yes, I think attaching to a live task would require suspending
the task first.

Detaching from a live task seems harder.  If the target task has
a receive right to a wrapper port to which rpctrace has forwarded
messages from an original port, but the target task has not read
those messages, then rpctrace would have to requeue them to the
original port, but it seems difficult to preserve the original
order of messages if other tasks are simultaneously sending more
messages to the original port.  This might be solved by adding a
kernel function that requeues the messages, or by implementing a
MACH_SEND_LIFO option for mach_msg.  However, strace with system
call tracing would avoid this as well as other problems.