unofficial mirror of bug-guile@gnu.org 
 help / color / mirror / Atom feed
From: Mikael Djurfeldt <mikael@djurfeldt.com>
To: Christopher Baines <mail@cbaines.net>
Cc: Mikael Djurfeldt <mikael@djurfeldt.com>, 70144@debbugs.gnu.org
Subject: bug#70144: system* affects signal handlers
Date: Wed, 3 Apr 2024 10:28:09 +0200	[thread overview]
Message-ID: <CAA2Xvw+5et9q_BrfN4dA8foZe+RkQEzowJBTCTS1Z3SXohrQ6g@mail.gmail.com> (raw)
In-Reply-To: <87msqbrga2.fsf@cbaines.net>

[-- 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 --]

  reply	other threads:[~2024-04-03  8:28 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-04-02 14:22 bug#70144: system* affects signal handlers Christopher Baines
2024-04-03  8:28 ` Mikael Djurfeldt [this message]
2024-05-02 14:17   ` Ludovic Courtès
2024-05-05 16:41     ` Josselin Poiret via Bug reports for GUILE, GNU's Ubiquitous Extension Language
2024-05-06 10:00       ` Ludovic Courtès

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/guile/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAA2Xvw+5et9q_BrfN4dA8foZe+RkQEzowJBTCTS1Z3SXohrQ6g@mail.gmail.com \
    --to=mikael@djurfeldt.com \
    --cc=70144@debbugs.gnu.org \
    --cc=mail@cbaines.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).