[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Guile-commits] 01/02: Document sigaction + SA_RESTART
From: |
Andy Wingo |
Subject: |
[Guile-commits] 01/02: Document sigaction + SA_RESTART |
Date: |
Tue, 21 Jun 2016 07:08:14 +0000 (UTC) |
wingo pushed a commit to branch master
in repository guile.
commit e877e1bccb8b288bf9742c97a3035e36cba5a70b
Author: Andy Wingo <address@hidden>
Date: Tue Jun 21 08:35:59 2016 +0200
Document sigaction + SA_RESTART
* doc/ref/posix.texi (Signals): Document interaction between Guile's
signal handling and SA_RESTART. Fixes #14640.
---
doc/ref/posix.texi | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
diff --git a/doc/ref/posix.texi b/doc/ref/posix.texi
index 09bcd81..118843d 100644
--- a/doc/ref/posix.texi
+++ b/doc/ref/posix.texi
@@ -2075,6 +2075,22 @@ restart the system call (as opposed to returning an
@code{EINTR} error
from that call).
@end defvar
+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
address@hidden 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.
+
The return value is a pair with information about the old handler as
described above.