On Saturday 21 October 2006 11:57, Kostik Belousov wrote: > On Sat, Oct 21, 2006 at 08:25:00AM +0800, David Xu wrote: > > On Thursday 19 October 2006 18:04, Kostik Belousov wrote: > > > The nfs_reply is sleeping with the PCATCH set. The question is why > > > SIGTSTP does not cause msleep to return with EINTR. > > > > I have not been tracking the thread. but if the thread is sleeping with > > PCATCH, the SIGTSTP should cause the process to stop unless the signal > > is masked by sigprocmask or the signal has an action handler been set, > > this is a correct behavior. > > David, > as I understand the report, the following happens. The nfs mount point with > intr option issued the request and waits for the reply. Some vnode locks > are held while waiting. Code needs to catch the signals to abort the > operation on user request. It uses msleep with PCATCH. The thread in > question has td_locks > 0. > > The SIGTSTP is delivered, and thread is stopped, while holding vnode lock. > How this situation shall be handled ? Namely, how to sleep while having the > ability to safely clean up on attempt of stopping ? Masking SIGTSTP is not > the option, due to SIGSTOP having the same results and not being blockable. > > [Would it be right to stop the threads only on returning from kernel to > user mode ?]
I know in the case, you want signal to interrupt the thread but don't want a job control signal to suspend the thread, but a PCATCH flag is not enough to tell the case. I think we are trying to fix the history problem of RELENG_4 or earlier. David Xu _______________________________________________ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
