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

Previous Next

Package: guile;

Reported by: ludovic.courtes <at> inria.fr (Ludovic Courtès)

Date: Mon, 17 Jun 2013 14:07:02 UTC

Severity: normal

Done: Andy Wingo <wingo <at> pobox.com>

Bug is archived. No further changes may be made.

Full log


Message #10 received at 14640-done <at> debbugs.gnu.org (full text, mbox):

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




This bug report was last modified 8 years and 363 days ago.

Previous Next


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