wingo pushed a commit to branch master in repository guile. commit e877e1bccb8b288bf9742c97a3035e36cba5a70b Author: Andy Wingo <wi...@pobox.com> 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 +@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. + The return value is a pair with information about the old handler as described above.