system* temporarily re-binds signal handlers to prevent the child process from killing the parent. Thus, it is not thread safe with regard to SIGINT (or SIGQUIT if available). So, your code has a race condition with respect to the signal handler. This common resource can, in principle, be handled the usual way by, for example, utilizing a mutex:

(use-modules (ice-9 threads))

(define sigint-mutex (make-mutex))

(define thread
(call-with-new-thread
(lambda ()
(with-mutex sigint-mutex
(system* "echo" "foo")))))

(with-mutex sigint-mutex
(sigaction SIGINT
(lambda (sig)
(peek "SIGINT handler")
(exit 1)))

(for-each
(lambda _
(sleep 1))
(iota 30)))

(join-thread thread)

(display "normal exit\n")

But if this was real code, another way would be to make sure that the code blocks are run in the order that you wish (which you did not want here since your very purpose was to provoke the collision of resources).

I'm leaving this bug open. *Should* system* re-bind the signal handlers? Should it really protect itself from the child? If so, we should probably document this behaviour in the reference manual.

Best regards,

Mikael

On Tue, Apr 2, 2024 at 4:28 PM Christopher Baines <mail@cbaines.net> wrote:

I've encountered a situation where signal handlers don't seem to
run. With the following program, sending it SIGINT won't trigger the
handler, however if you remove the system* call, then the handler will
run.

(use-modules (ice-9 threads))

(call-with-new-thread
(lambda ()
;; Remove the following system* call to fix the handler
(system* "echo" "foo")))

(sigaction SIGINT
(lambda (sig)
(peek "SIGINT handler")
(exit 1)))

(for-each
(lambda _
(sleep 1))
(iota 30))

(display "normal exit\n")