Hi, On 09-12-28 上午3:56, Carl Fredrik Hammar wrote: > > OK, I think I have a vague picture of what is going on: > ports_interrupt_self_on_port_death > ports_interrupt_self_on_notification > ports_interrupt_rpc_on_notification, > which requests notification (to the same port as > auth_server_authenticate). > > When rendezvous port dies we get the notification: > ports_notify_server > ports_do_mach_notify_dead_name > ports_dead_name > ports_interrupt_notified_rpcs > hurd_thread_cancel (in glibc) > _hurdsig_abort_rpcs, > which does some funky stuff that seems to hijack any pending RPCs > to make them return EINTR. So the registered deadname notification can cancel the RPC (i.e, auth_server_authenticate RPC is this case)? and the thread will somehow jump to some place to return EINTR and doesn't execute hurd_condition_wait() and the code below it? > > If the notification request is canceled before auth_user_authenticate > returns there should be no problem. I don't know how to do that, as > libports doesn't seem to have a function for it. The primitive function > would be mach_port_request_notification with a null port, but I assume > there is other stuff to clean up. Is it OK to extend libports to have some function to cancel the notification request?
Zheng Da
