[bug#54997] [PATCH v2 04/15] linux-container: Ensure signal-handling asyncs get a chance to run.

[Ludovic Courtès]

Previously we could enter the blocking 'waitpid' call and miss an
opportunity to run the signal handler async.

* gnu/build/linux-container.scm (call-with-container)
[periodically-schedule-asyncs]: New procedure.
[install-signal-handlers]: Call it.
---
 gnu/build/linux-container.scm | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/gnu/build/linux-container.scm b/gnu/build/linux-container.scm
index 03c01439ce..1fac8f4b92 100644
--- a/gnu/build/linux-container.scm
+++ b/gnu/build/linux-container.scm
@@ -327,11 +327,20 @@ (define* (call-with-container mounts thunk #:key 
(namespaces %namespaces)
 Note that if THUNK needs to load any additional Guile modules, the relevant
 module files must be present in one of the mappings in MOUNTS and the Guile
 load path must be adjusted as needed."
+  (define (periodically-schedule-asyncs)
+    ;; XXX: In Guile there's a time window where a signal-handling async could
+    ;; be queued without being processed by the time we enter a blocking
+    ;; syscall like waitpid(2) (info "(guile) Signals").  This terrible hack
+    ;; ensures pending asyncs get a chance to run periodically.
+    (sigaction SIGALRM (lambda _ (alarm 1)))
+    (alarm 1))
+
   (define (install-signal-handlers pid)
     ;; Install handlers that forward signals to PID.
     (define (relay-signal signal)
       (false-if-exception (kill pid signal)))
 
+    (periodically-schedule-asyncs)
     (for-each (lambda (signal)
                 (sigaction signal relay-signal))
               relayed-signals))
-- 
2.35.1