Re: Sleeping thread not receive signal until it wakes up

[Sergey Vlasov <vsu@altlinux.ru>]

[-- Attachment #1: Type: text/plain, Size: 1591 bytes --]

On Fri, 9 Mar 2007 16:10:29 -0800 Luong Ngo wrote:

> Thanks Parav, adding singal_allow(SIGALRM) wakeup the blocking
> interruptible_sleep_on and checking the signal_pending would return
> true now.

This means that there is also a bug in your userspace program -
somehow when it invokes ioctl(), it has SIGALRM blocked.  Use
sigprocmask() (or pthread_sigmask() if your program is multithreaded)
to ensure that SIGALRM is not blocked when you are expecting it to be
processed.  (Even if your program does not block SIGALRM, it may
inherit a blocked SIGALRM from another program which have started it,
so the safest way is to unblock SIGALRM explicitly.)

Using allow_signal() is needed only if you create a kernel thread and
want that thread to handle signals.

> But a quick question is when detecting signal_pending, I
> return -ERESTARTSYS, but the user process receive the return value of
> ioctl call is -1, shouldn't it be -4 for EINTR?

This is handled by syscall wrappers in libc - when the kernel returns
an error code from a syscall, the syscall wrapper function puts the
code into the per-thread errno variable and returns -1 to its caller.
Your userspace code should check errno for the actual error code when
it receives -1 from ioctl().

And the ERESTARTSYS error is really special - it never actually gets
returned to the userspace program; instead, the syscall return code in
the kernel catches it and either restarts the syscall after the signal
handler completes, or converts the error code to EINTR; one of these
actions is selected by the SA_RESTART flag to sigaction().

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]