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.devel Subject: Re: [PATCH] At-exit hook Date: Thu, 7 Nov 2024 14:28:46 +0100 Message-ID: References: <20241107122308.ZnP72D00T42S6aw01nP8co@laurent.telenet-ops.be> <20241107120925.87d4b80c9f289d18eec437ad@gmail.com> <20241107122700.b37d3e8d2c1c09203147117e@gmail.com> Reply-To: mikael@djurfeldt.com Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000e6e6e20626529d03" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="19814"; mail-complaints-to="usenet@ciao.gmane.io" Cc: guile-devel , Mikael Djurfeldt To: Mailer Original-X-From: guile-devel-bounces+guile-devel=m.gmane-mx.org@gnu.org Thu Nov 07 14:29:25 2024 Return-path: Envelope-to: guile-devel@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 1t92Zh-00050R-Bu for guile-devel@m.gmane-mx.org; Thu, 07 Nov 2024 14:29:25 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1t92ZK-0005Ar-PV; Thu, 07 Nov 2024 08:29:02 -0500 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 1t92ZJ-00059u-Ea for guile-devel@gnu.org; Thu, 07 Nov 2024 08:29:01 -0500 Original-Received: from mail-vk1-f178.google.com ([209.85.221.178]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1t92ZH-0003jE-S3 for guile-devel@gnu.org; Thu, 07 Nov 2024 08:29:01 -0500 Original-Received: by mail-vk1-f178.google.com with SMTP id 71dfb90a1353d-5139cd0032cso426997e0c.2 for ; Thu, 07 Nov 2024 05:28:59 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1730986139; x=1731590939; 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=Au4+wpKIsWdNrRdjxEQA3zPIZoMXZvr7gAoyMNye0Lo=; b=lw0l/jveW7HY0cJpV/5EkcIwG/2ntkmxKJdHa+sqwJpFt0TsZI2YAxlUDJgjr3sS08 Gb/RRAVnCfc3t7H32UZG9fkQrcLiMqyLLd3ozG1shICA8PMacmauMNaZ3S4D0BbUQAbH YBjH4lObPcZwKQLpPkgx+JQDYlMgShiXMHfpteU3/k1S/TGC484NXgMjq8kz7WmtCS2v ZJ2trfj7vreh9atQYW6dQ2u3OpdJ4jxnUTIOFV2hyTeKV5zLjz0CTpxeq8xTcfL6CPHu FjZj+sG/sDwcqMYlmXqvpgoAbbl+4vMpwaiXYufSJBEAd1oGAtGb+f9ozmKDJJdx+j4b nsmw== X-Gm-Message-State: AOJu0YwFoSD0RODFvQUdimNH2qxLGX2f56MKVRM5BrnowX5aIyQZl/JY bThr9I/WPqNq0suEZEB56NqSuadKbVPDSPS7GX4dnM/2dd8xbc5xRojueCSS8TObdnnw0DRznpg uTAtUXIbSXYC9krUWrK9YwNZR8aw5rQ== X-Google-Smtp-Source: AGHT+IHB4usZYu7MWL/Rj6PmeG5UFxOE3U5eplk7XwBD9upfeVSQIkSy8ihVBTdzawYQYiOfiHfL5kxFujh2zpNUbgg= X-Received: by 2002:a05:6122:901:b0:50d:66e1:826c with SMTP id 71dfb90a1353d-513fa44461fmr1082004e0c.11.1730986138590; Thu, 07 Nov 2024 05:28:58 -0800 (PST) In-Reply-To: <20241107122700.b37d3e8d2c1c09203147117e@gmail.com> Received-SPF: pass client-ip=209.85.221.178; envelope-from=mdjurfeldt@gmail.com; helo=mail-vk1-f178.google.com X-Spam_score_int: -15 X-Spam_score: -1.6 X-Spam_bar: - X-Spam_report: (-1.6 / 5.0 requ) BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-devel-bounces+guile-devel=m.gmane-mx.org@gnu.org Original-Sender: guile-devel-bounces+guile-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.lisp.guile.devel:22764 Archived-At: --000000000000e6e6e20626529d03 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable OK, so people have brought up two issues: 1. It is for various reasons not recommended to call atexit() from a dynamically linked library (which Guile already does before my suggested change, n.b.). 2. It is not async signal safe. A suggested remedy would then be: Instead of calling the at-exit-hook from really_cleanup_for_exit, we could call it (still within an scm_with_guile) from the end of scm_boot_guile(), just before exit(), with the disadvantage that it wouldn't be called if main_func() calls exit on its own. It's kind of a pity that we didn't early on introduce some kind of scm_finalize_guile() which the user would have to call when done with the library... And, well, perhaps we should block asyncs, but I don't know about signals with this new setup. Best regards, Mikael On Thu, Nov 7, 2024 at 1:26=E2=80=AFPM Mailer wrot= e: > On Thu, 7 Nov 2024 12:09:25 +0000 > Mailer wrote: > > On Thu, 7 Nov 2024 12:23:08 +0100 > > Maxime Devos wrote: > > > =E2=80=98atexit=E2=80=99 functions are run at =E2=80=98exit=E2=80=99.= =E2=80=98exit=E2=80=99 can be run from signal > > > handlers (*). Since the hook runs Scheme code, it could do a lot of > > > AC-unsafe things, resulting in problems. > > > > > > (*) glibc documentation says =E2=80=98exit=E2=80=99 is AC-unsafe, but= this is > > > unsupported by POSIX AFAICT. OTOH the same applies to even =E2=80=98m= alloc=E2=80=99, > > > so likely I=E2=80=99m looking in the wrong places. > > > > I think you meant async-signal-safe (AS-safe). 'exit' is not a-s-s and > > cannot be called in a signal handler (for example it can flush buffers) > > whereas '_exit' is a-s-s. Furthermore a registered handler cannot > > itself safely call 'exit'. > > > > I believe the main reason that use of 'atexit' or 'on_exit' is > > discouraged is that it does not handle abnormal process termination. > > (Registered handlers also don't run on termination by '_exit', but that > > is usually what you want.) > > I believe also that use of 'atexit' is discouraged in dynamically linked > libraries because of the uncertain timing of the unloading of the > library, but I think in fact glibc is OK with this, so I guess it may > depend on your libc. > > Chris > > --000000000000e6e6e20626529d03 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
OK, so people have brought up two issues:
<= br>
1. It is for various reasons not recommended to call atexit()= from a dynamically linked library (which Guile already does before my sugg= ested change, n.b.).

2. It is not async signal saf= e.

A suggested remedy would then be:
Instead of calling the at-exit-hook from really_cleanup_for_exi= t, we could call it (still within an scm_with_guile) from the end of scm_bo= ot_guile(), just before exit(), with the disadvantage that it wouldn't = be called if main_func() calls exit on its own. It's kind of a pity tha= t we didn't early on introduce some kind of scm_finalize_guile() which = the user would have to call when done with the library...

And, well, perhaps we should block asyncs, but I don't know abo= ut signals with this new setup.

Best regards,
Mikael

On Thu, Nov 7, 2024 at 1:26=E2=80=AFPM Mailer <vine24683579@gmail.com> wrote= :
On Thu, 7 Nov = 2024 12:09:25 +0000
Mailer <vine= 24683579@gmail.com> wrote:
> On Thu, 7 Nov 2024 12:23:08 +0100
> Maxime Devos <maximedevos@telenet.be> wrote:
> > =E2=80=98atexit=E2=80=99 functions are run at =E2=80=98exit=E2=80= =99. =E2=80=98exit=E2=80=99 can be run from signal
> > handlers (*). Since the hook runs Scheme code, it could do a lot = of
> > AC-unsafe things, resulting in problems.
> >
> > (*) glibc documentation says =E2=80=98exit=E2=80=99 is AC-unsafe,= but this is
> > unsupported by POSIX AFAICT. OTOH the same applies to even =E2=80= =98malloc=E2=80=99,
> > so likely I=E2=80=99m looking in the wrong places.
>
> I think you meant async-signal-safe (AS-safe).=C2=A0 'exit' is= not a-s-s and
> cannot be called in a signal handler (for example it can flush buffers= )
> whereas '_exit' is a-s-s.=C2=A0 Furthermore a registered handl= er cannot
> itself safely call 'exit'.
>
> I believe the main reason that use of 'atexit' or 'on_exit= ' is
> discouraged is that it does not handle abnormal process termination. > (Registered handlers also don't run on termination by '_exit&#= 39;, but that
> is usually what you want.)

I believe also that use of 'atexit' is discouraged in dynamically l= inked
libraries because of the uncertain timing of the unloading of the
library, but I think in fact glibc is OK with this, so I guess it may
depend on your libc.

Chris

--000000000000e6e6e20626529d03--