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). The RPC that could get canceled is auth_server_authenticate(). Mmm, that makes me realize that this could be the link with ext2fs indeed. > > 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. > As Fredrik said and as I understand, while the server side of > auth_server_authenticate RPC is waiting for the signal from the > auth_user_authenticate, auth_server_authenticate RPC can be canceled by the > deadname notification if the client gets scheduled first and destroys the > rendezvous port and thus the auth_server_authenticate RPC returns EINTR. Right. > The right thing to do is that before the server side of > auth_user_authenticate RPC returns, it cancels the deadname > notification. 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! Samuel