"Brent W. Baccala" <cos...@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.
