hi thanks a lot for every comment! i've completed a version of the code using helper functions from include/linux/kthread.h file and non blocking sock_recvmsg() as suggested... this is working fine, if somebody were interested in reveive a copy please ask to me. from now i will try to do a version using blocking sock_recvmsg() and trying to kill it cleanly with kthread_stop helper function. at this moment, i've tried it and kthread_stop() can't interrupt sock_recvmsg()... i will take a deep look on how they work to get it. thanks again, toni El dt 20 de 12 del 2005 a les 17:10 +0700, en/na Mulyadi Santosa va escriure: > hello Jan... > > > That's not true. They are *handled* only when switching to > > user-space. But they can be checked from many places in kernel. > > Yes, you're correct. I just realized it later after re-studying UTLK 2, > that's why I try to correct it in the 2nd reply to Toni. I hope it will > clear things up. > > > Such syscalls return -EINTR, -ERESTARTSYS, -ERESTARTNOINTR or > > -ERESTARTNOHAND (see linux/errno.h). The first is simply returned to > > userland as errno value (eg. select and poll do this), the other > > three tell the signal trampoline to restart the syscall. Note that > > non-local exit from signal handler bypasses this trampoline, so the > > kernel never knows for sure whether the signal will be restarted or > > not. > > I don't understand, what do you mean by non-local exit? > > > In majority of cases, the process receiving the signal is *NOT* > > running at the moment it receives the signal. What is the other thing > > running is completely irrelevant. The receipt of a signal puts it in > > the queue for handling during next return to userland and makes sure > > the process is schedules as soon as possible, unless it's in > > uninterruptible state. > > Yes, you're correct, re-scheduling is the key to make the target process > "acknowledges" the signal ASAP. > > About the uninterruptible state, that's why I suggest Toni to take a > deep look on how sock_recvmsg() works, does it put the process in > interruptible state or the uninterruptible one. > > Let's wait for his further investigation...I am sure the answer is > already near :) > > Once again, thanks for your time to correct my previous statements > > regards > > Mulyadi > > -- Kernelnewbies: Help each other learn about the Linux kernel. Archive: http://mail.nl.linux.org/kernelnewbies/ FAQ: http://kernelnewbies.org/faq/
