unofficial mirror of bug-guile@gnu.org 
 help / color / mirror / Atom feed
* bug#70144: system* affects signal handlers
@ 2024-04-02 14:22 Christopher Baines
  2024-04-03  8:28 ` Mikael Djurfeldt
  0 siblings, 1 reply; 2+ messages in thread
From: Christopher Baines @ 2024-04-02 14:22 UTC (permalink / raw)
  To: 70144

[-- Attachment #1: Type: text/plain, Size: 544 bytes --]

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")

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 987 bytes --]

^ permalink raw reply	[flat|nested] 2+ messages in thread

* bug#70144: system* affects signal handlers
  2024-04-02 14:22 bug#70144: system* affects signal handlers Christopher Baines
@ 2024-04-03  8:28 ` Mikael Djurfeldt
  0 siblings, 0 replies; 2+ messages in thread
From: Mikael Djurfeldt @ 2024-04-03  8:28 UTC (permalink / raw)
  To: Christopher Baines; +Cc: Mikael Djurfeldt, 70144

[-- Attachment #1: Type: text/plain, Size: 1919 bytes --]

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")
>

[-- Attachment #2: Type: text/html, Size: 2540 bytes --]

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2024-04-03  8:28 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2024-04-02 14:22 bug#70144: system* affects signal handlers Christopher Baines
2024-04-03  8:28 ` Mikael Djurfeldt

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).