On Sat, Dec 17, 2005 at 06:31:04 +0700, Mulyadi Santosa wrote: > > if pending signals are being checked only when switching back to user That's not true. They are *handled* only when switching to user-space. But they can be checked from many places in kernel. > > space, why it's allowed to use signals in kernel space (between > > kernel objects) .. i've read once that in kernel space you can't use > > signals , correct me please > > Honestly I really don't know the core idea why it's allowed to use > signals between kernel objects. IMHO, if the kernel objects is working > on behalf of a process, maybe the signal is useful, but if not (e.g Receipt of a signal wakes up processes in interruptible sleep (TASK_INTERRUPTIBLE state). Many syscalls wait for whatever they need in that state and return prematurely if a signal is received. There is a signal_pending() function to test whether there is a signal queued for current process. 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. > working in interrupt context), I don't see any usefulness as signal is > always queued to certain task_struct. 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. > Check ret_from_syscall in entry.S, this is where I got the above > conclusion. But again, you can CMIIW. -- Jan 'Bulb' Hudec <bulb@xxxxxx>
Attachment:
signature.asc
Description: Digital signature
