Subject: bug#14640: closed (Re: bug#14640: SA_RESTART prevents execution of signal handlers)

From: [email-masked] (GNU bug Tracking System)
Date: Tue, 21 Jun 2016 06:38:02 +0000

Your bug report

#14640: SA_RESTART prevents execution of signal handlers

which was filed against the guile package, has been closed.

The explanation is attached below, along with your original report.
If you require more details, please reply to [email-masked].

-- 
14640: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=14640
GNU Bug Tracking System
Contact [email-masked] with problems

Subject: Re: bug#14640: SA_RESTART prevents execution of signal handlers
From: Andy Wingo <[email-masked]>
To: [email-masked] (Ludovic Courtès)
Cc: [email-masked]
Date: Tue, 21 Jun 2016 08:37:37 +0200
List-Id: <debbugs-submit.debbugs.gnu.org>

On Mon 17 Jun 2013 15:54, [email-masked] (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

Subject: SA_RESTART prevents execution of signal handlers
From: [email-masked] (Ludovic Courtès)
To: [email-masked]
Date: Mon, 17 Jun 2013 15:54:45 +0200
List-Id: <debbugs-submit.debbugs.gnu.org>

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’.