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/
