--- Begin Message ---
|
Subject: |
SA_RESTART prevents execution of signal handlers |
|
Date: |
Mon, 17 Jun 2013 15:54:45 +0200 |
|
User-agent: |
Gnus/5.130007 (Ma Gnus v0.7) Emacs/24.3 (gnu/linux) |
When using SA_RESTART, signal handlers are never executed, as in this
example (checked on 2.0.9+):
--8<---------------cut here---------------start------------->8---
(sigaction SIGALRM
(lambda (signum)
(pk 'sig signum))
SA_RESTART)
(alarm 3)
(pk 'char (read-char))
--8<---------------cut here---------------end--------------->8---
Presumably this is because the read(2) syscall is automatically
restarted, leaving no chance for the handler async to run.
Ludo’.
--- End Message ---
--- Begin Message ---
|
Subject: |
Re: bug#14640: SA_RESTART prevents execution of signal handlers |
|
Date: |
Tue, 21 Jun 2016 08:37:37 +0200 |
|
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) |
On Mon 17 Jun 2013 15:54, address@hidden (Ludovic Courtès) writes:
> When using SA_RESTART, signal handlers are never executed, as in this
> example (checked on 2.0.9+):
>
> (sigaction SIGALRM
> (lambda (signum)
> (pk 'sig signum))
> SA_RESTART)
> (alarm 3)
> (pk 'char (read-char))
>
> Presumably this is because the read(2) syscall is automatically
> restarted, leaving no chance for the handler async to run.
Thinking about this a bit -- since we always handle signals
asynchronously and have no intention of handling them synchronously,
then we just have to document this behavior. Done in e877e1b:
Guile handles signals asynchronously. When it receives a signal, the
synchronous signal handler just records the fact that a signal was
received and sets a flag to tell the relevant Guile thread that it has a
pending signal. When the Guile thread checks the pending-interrupt
flag, it will arrange to run the asynchronous part of the signal
handler, which is the handler attached by @code{sigaction}.
This strategy has some perhaps-unexpected interactions with the
@code{SA_RESTART} flag, though: because the synchronous handler doesn't
do very much, and notably it doesn't run the Guile handler, it's
impossible to interrupt a thread stuck in a long-running system call via
a signal handler that is installed with @code{SA_RESTART}: the
synchronous handler just records the pending interrupt, but then the
system call resumes and Guile doesn't have a chance to actually check
the flag and run the asynchronous handler. That's just how it is.
Andy
--- End Message ---