GNU bug report logs - #14640
SA_RESTART prevents execution of signal handlers

Previous Next

Full log

View this message in rfc822 format

From: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: Andy Wingo <wingo <at> pobox.com>
Cc: tracker <at> debbugs.gnu.org
Subject: bug#14640: closed (SA_RESTART prevents execution of signal handlers)
Date: Tue, 21 Jun 2016 06:38:02 +0000

[Message part 1 (text/plain, inline)]

Your message dated Tue, 21 Jun 2016 08:37:37 +0200
with message-id <87twgn59ou.fsf <at> pobox.com>
and subject line Re: bug#14640: SA_RESTART prevents execution of signal handlers
has caused the debbugs.gnu.org bug report #14640,
regarding SA_RESTART prevents execution of signal handlers
to be marked as done.

(If you believe you have received this mail in error, please contact
help-debbugs <at> gnu.org.)


-- 
14640: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=14640
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems

[Message part 2 (message/rfc822, inline)]

From: ludovic.courtes <at> inria.fr (Ludovic Courtès)
To: bug-guile <at> gnu.org
Subject: SA_RESTART prevents execution of signal handlers
Date: Mon, 17 Jun 2013 15:54:45 +0200

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

[Message part 3 (message/rfc822, inline)]

From: Andy Wingo <wingo <at> pobox.com>
To: ludovic.courtes <at> inria.fr (Ludovic Courtès)
Cc: 14640-done <at> debbugs.gnu.org
Subject: Re: bug#14640: SA_RESTART prevents execution of signal handlers
Date: Tue, 21 Jun 2016 08:37:37 +0200

On Mon 17 Jun 2013 15:54, ludovic.courtes <at> inria.fr (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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.