> > I've done this in the past so that the code sleeps interruptibly > > unless there is a signal pending - which would cause it to return > > early. > > > > /* Tell scheduler we are going to sleep... */ > > if (signal_pending(current)) > > /* We don't want waking immediately (again) */ > > sleep_state = TASK_UNINTERRUPTIBLE; > > else > > sleep_state = TASK_INTERRUPTIBLE; > > set_current_state(sleep_state); > > If this is for kernel threads, I think you can wipe the pending state; > not entirely sure how signals interact with kthreads; Oleg will know.
I did take me a while to manage to use kthreads, and we probably still have customers who insist on using pre 2.6.18 kernels! (In which case the processes are children of a daemon that only return to userspace in order to exit.) We also need to send signals (to get the process out of blocking socket calls), so I have to use force_sig() to get the signal noticed. The other issue was tidyup - I had to find module_put_and_exit(). David -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/