Da Zheng, le Mon 28 Dec 2009 17:59:55 +0800, a écrit : > 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?
It does, but that's not a problem in the case of auth now that I have patched it. Where this is a problem is in ext2fs which was calling auth_server_authenticate(). That function gets an EINTR from mach_msg and returns 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? I actually believe that's already the case: libports remembers the notification request and disables it on RPC termination, which should be enough for itself. What I still don't understand is the link between auth requesting a notification and ext2fs also getting the EINTR. Samuel
