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 --]
next prev parent 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).