Samuel Thibault, le Mon 28 Dec 2009 11:14:04 +0100, a écrit : > 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.
Err, no, I mean the RPC is interrupted and hurd_condition_wait returns 1 instead of 0, but that's not a problem etc. Samuel