Da Zheng, le Mon 28 Dec 2009 19:43:11 +0800, a écrit : > On 09-12-28 下午7:21, Samuel Thibault wrote: > > Da Zheng, le Mon 28 Dec 2009 19:03:26 +0800, a écrit : > >> Doesn't it mean the RPC on userauth (namely, auth_user_authenticate) > >> is to be canceled? > > > > No, here the auth_user_authenticate() RPC is over (else the initiator > > wouldn't have destroyed the rendezvous port). > What do you mean by that? I was talking about which RPC will be canceled by > the > deadname notification requested in the server side of > auth_server_authenticate.
Right, but auth_user_authenticate can't be canceled since it's finished by the time the rendezvous port is destroyed. > > Mmm, thinking again about it, while I said in a previous mail that > > I tried and it failed, that was with the original version, not > > with my patched version. In the original version, we do let the > > auth_user_authenticate RPC return before hurd_condition_wait wakes in > > the auth_server_authenticate RPC server, which will bring the interrupt. > > > >> In this case, auth_server_authenticate RPC can never be interrupted > >> by the deadname notification any more even if the rendezvous port is > >> destroyed before auth_server_authenticate RPC gets its chance to run. > > > > Right. So it should work, good! > Now the problem is how to cancel the notification request explicitly. It should just be a matter of adding the support in libports that requests it from the kernel but also cleans it in the lists, as Frederik said. Samuel
