From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Mikael Djurfeldt Newsgroups: gmane.lisp.guile.bugs Subject: bug#70144: system* affects signal handlers Date: Wed, 3 Apr 2024 10:28:09 +0200 Message-ID: References: <87msqbrga2.fsf@cbaines.net> Reply-To: mikael@djurfeldt.com Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="0000000000005d391506152d01ac" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="33160"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Mikael Djurfeldt , 70144@debbugs.gnu.org To: Christopher Baines Original-X-From: bug-guile-bounces+guile-bugs=m.gmane-mx.org@gnu.org Wed Apr 03 10:29:11 2024 Return-path: Envelope-to: guile-bugs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1rrvza-0008P2-Tm for guile-bugs@m.gmane-mx.org; Wed, 03 Apr 2024 10:29:11 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rrvzP-0004rX-GS; Wed, 03 Apr 2024 04:28:59 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rrvzN-0004rL-UL for bug-guile@gnu.org; Wed, 03 Apr 2024 04:28:57 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1rrvzN-0000KB-MP for bug-guile@gnu.org; Wed, 03 Apr 2024 04:28:57 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1rrvzR-0006ad-TB for bug-guile@gnu.org; Wed, 03 Apr 2024 04:29:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Mikael Djurfeldt Original-Sender: "Debbugs-submit" Resent-CC: bug-guile@gnu.org Resent-Date: Wed, 03 Apr 2024 08:29:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 70144 X-GNU-PR-Package: guile Original-Received: via spool by 70144-submit@debbugs.gnu.org id=B70144.171213291525291 (code B ref 70144); Wed, 03 Apr 2024 08:29:01 +0000 Original-Received: (at 70144) by debbugs.gnu.org; 3 Apr 2024 08:28:35 +0000 Original-Received: from localhost ([127.0.0.1]:56991 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rrvz0-0006Zq-4y for submit@debbugs.gnu.org; Wed, 03 Apr 2024 04:28:34 -0400 Original-Received: from mail-ua1-f52.google.com ([209.85.222.52]:53564) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rrvyx-0006Z3-4n for 70144@debbugs.gnu.org; Wed, 03 Apr 2024 04:28:32 -0400 Original-Received: by mail-ua1-f52.google.com with SMTP id a1e0cc1a2514c-7e3b3e33aa7so311971241.3 for <70144@debbugs.gnu.org>; Wed, 03 Apr 2024 01:28:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1712132901; x=1712737701; h=cc:to:subject:message-id:date:from:reply-to:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=/NHKnkUwWH8cRWvne61axlH6wxCuwQYGH6E9bDG/yno=; b=QYSChWD4lEf78B4QIATh42p6g6VGsEl4SNYAsSOJtDtWQwhLSd5As3X38BzTqLgXoN hHeuO3qwg+hIR0x2BEfgwH18WHDGszisfBzCSAT3jltVNrE0KwKd08iBpfDbZUwS7OOn kcLN1EgL08iceU02aGQIqLLtCxXfantc8NQjJvSAoDbNY3vUkKxC8DEDSdGKAZXifU6v d4o0h1Oj+Sb/HjRQ6THx16SplG+cRQP0Dd7cELPN6k2CiKPiVrtSdqnGyJS+vne4TB8y 1BmEDiv0IN87DRZFoPLqza+aLg6Arb4DSazS0nIud8S9W4Buuk/qsezTgUOzonZ3HYXp 61uQ== X-Gm-Message-State: AOJu0YxWEINhRIkmIfGCpcJZVtKHMUbo8FF4NYpDX1lep8zyWquGFk9E C16rACAqH7dIBE1t/pakAXXZsES8zybA4DiCdtgTs9rUDdfQOHubzX/M1K/S1WTyXbfsC0woBE0 gFZqg/y9nssP+Rm07EoL9gf4FWk8= X-Google-Smtp-Source: AGHT+IGjoy/o1qJVNMc/KpxQNfeD/5M6a9n1owFcQ6lInMlod6AUBbphwOSyinYMdA/UAzC+qlPqmBscbV3xgoP4Cj8= X-Received: by 2002:a67:b40a:0:b0:478:6ced:3385 with SMTP id x10-20020a67b40a000000b004786ced3385mr7681128vsl.11.1712132900859; Wed, 03 Apr 2024 01:28:20 -0700 (PDT) In-Reply-To: <87msqbrga2.fsf@cbaines.net> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-guile@gnu.org List-Id: "Bug reports for GUILE, GNU's Ubiquitous Extension Language" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-guile-bounces+guile-bugs=m.gmane-mx.org@gnu.org Original-Sender: bug-guile-bounces+guile-bugs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.lisp.guile.bugs:10802 Archived-At: --0000000000005d391506152d01ac Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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=E2=80=AFPM Christopher Baines 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") > --0000000000005d391506152d01ac Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
system* temporarily re-binds signal handlers to preve= nt the child process from killing the parent. Thus, it is not thread safe w= ith regard to SIGINT (or SIGQUIT if available). So, your code has a race co= ndition with respect to the signal handler. This common resource can, in pr= inciple, be handled the usual way by, for example, utilizing a mutex:
=

(use-modules (ice-9 threads))

(define sigint-mut= ex (make-mutex))

(define thread
=C2=A0 (call-with-new-thread
= =C2=A0 =C2=A0(lambda ()
=C2=A0 =C2=A0 =C2=A0(with-mutex sigint-mutex
= =C2=A0 =C2=A0 =C2=A0 =C2=A0(system* "echo" "foo")))))
(with-mutex sigint-mutex
=C2=A0 (sigaction SIGINT
=C2=A0 =C2=A0= (lambda (sig)
=C2=A0 =C2=A0 =C2=A0 (peek "SIGINT handler")=C2=A0 =C2=A0 =C2=A0 (exit 1)))

=C2=A0 (for-each
=C2=A0 =C2=A0(l= ambda _
=C2=A0 =C2=A0 =C2=A0(sleep 1))
=C2=A0 =C2=A0(iota 30)))
(join-thread thread)

(display "normal exit\n")

But if this was real code, another way would be to make sur= e that the code blocks are run in the order that you wish (which you did no= t want here since your very purpose was to provoke the collision of resourc= es).

I'm leaving this bug open. *Should* syste= m* re-bind the signal handlers? Should it really protect itself from the ch= ild? If so, we should probably document this behaviour in the reference man= ual.

Best regards,
Mikael

On Tu= e, Apr 2, 2024 at 4:28=E2=80=AFPM Christopher Baines <mail@cbaines.net> wrote:
I've encountered a situation where si= gnal 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.

=C2=A0 (use-modules (ice-9 threads))

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

=C2=A0 (sigaction SIGINT
=C2=A0 =C2=A0 (lambda (sig)
=C2=A0 =C2=A0 =C2=A0 (peek "SIGINT handler")
=C2=A0 =C2=A0 =C2=A0 (exit 1)))

=C2=A0 (for-each
=C2=A0 =C2=A0(lambda _
=C2=A0 =C2=A0 =C2=A0(sleep 1))
=C2=A0 =C2=A0(iota 30))

=C2=A0 (display "normal exit\n")
--0000000000005d391506152d01ac--