From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Maxime Devos Newsgroups: gmane.lisp.guile.devel Subject: RE: [PATCH] At-exit hook Date: Thu, 7 Nov 2024 23:18:10 +0100 Message-ID: <20241107231810.ZyJA2D00E42S6aw01yJAnr@laurent.telenet-ops.be> References: <20241107122308.ZnP72D00T42S6aw01nP8co@laurent.telenet-ops.be> <20241107120925.87d4b80c9f289d18eec437ad@gmail.com> <20241107171045.ZsAk2D00S42S6aw01sAkk9@laurent.telenet-ops.be> <20241107195157.5a8cad633d4370bf4c48f21f@gmail.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="_796FB59E-0091-4FCA-BB42-5D7AE49C89DF_" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="15246"; mail-complaints-to="usenet@ciao.gmane.io" To: Mailer , guile-devel Original-X-From: guile-devel-bounces+guile-devel=m.gmane-mx.org@gnu.org Thu Nov 07 23:18:48 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 1t9Apz-0003q1-U0 for guile-devel@m.gmane-mx.org; Thu, 07 Nov 2024 23:18:48 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1t9ApZ-0004xN-J2; Thu, 07 Nov 2024 17:18:22 -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 1t9ApW-0004wq-Bk for guile-devel@gnu.org; Thu, 07 Nov 2024 17:18:18 -0500 Original-Received: from laurent.telenet-ops.be ([2a02:1800:110:4::f00:19]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1t9ApT-0006ER-Hi for guile-devel@gnu.org; Thu, 07 Nov 2024 17:18:18 -0500 Original-Received: from [IPv6:2a02:1811:8c0e:ef00:45f4:a590:36c8:c699] ([IPv6:2a02:1811:8c0e:ef00:45f4:a590:36c8:c699]) by laurent.telenet-ops.be with cmsmtp id ZyJA2D00E42S6aw01yJAnr; Thu, 07 Nov 2024 23:18:10 +0100 Importance: normal X-Priority: 3 In-Reply-To: <20241107195157.5a8cad633d4370bf4c48f21f@gmail.com> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telenet.be; s=r24; t=1731017890; bh=2Wer+bOGMlC3C9q4PWJfAnTNQpJ8sO3rF6AoGE8whX0=; h=Message-ID:MIME-Version:To:From:Subject:Date:In-Reply-To: References:Content-Type:From; b=k0lgmxkUcJzr5UNIEf0rr7lk1pTEycgAxM1kd/gfUej4iHGBFwnp4FeGu8RJ+K9nz eBH7I6cE0ZcA2jhm3z/qNbsy9OL2EqS9V4xQetiIaDpLOtbjKzg8HdpsJvnV1oF1nH O8G4DYPoLdX7yec0uHDSPfmOnPYw/KQt3kOnNEQtBTF5riVV2+WxFEU30RDd2A2Kmj zXmsXtnYxejXm5qibjNg+4RBHUB/ZSFy4+pALFPrrot/8fbfSEYRsta3se2VxuCQeb jYf+r2NsMjn21D9BC5OOuLK0p6MauHaZhjYXvKdxxvwH2c3szhQphAVK2i1FJbdaQX aodvC3pGz1RAw== Received-SPF: pass client-ip=2a02:1800:110:4::f00:19; envelope-from=maximedevos@telenet.be; helo=laurent.telenet-ops.be X-Spam_score_int: -27 X-Spam_score: -2.8 X-Spam_bar: -- X-Spam_report: (-2.8 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham 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:22767 Archived-At: --_796FB59E-0091-4FCA-BB42-5D7AE49C89DF_ Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" On Thu, 7 Nov 2024 17:10:45 +0100 Maxime Devos 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. > >>=20 > >> (*) 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=98ma= lloc=E2=80=99, > >> so likely I=E2=80=99m looking in the wrong places. >=20 > >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'. [=E2=80=A6] >=20 > No, I did mean exactly what I wrote. Read the glibc documentation of =E2= =80=98exit=E2=80=99 and you=E2=80=99ll see. (Likewise for the POSIX page fo= r =E2=80=98exit=E2=80=99 =E2=80=93 POSIX does not seem to restrict things t= o _outside_ signal handlers.) >=20 > Also, when two authorative sources (POSIX and glibc in this case) have co= ntrary claims, then simply repeating one of those claim does not help at al= l, you would need to explain the cause of the discrepancy instead. >=20 > That =E2=80=98exit=E2=80=99 flushes buffers does not imply that =E2=80=98= exit=E2=80=99 is async-unsafe, alternatives include buffer flushing being s= afe, =E2=80=98exit=E2=80=99 having its own implementation of flushing that = is AC-safe, or =E2=80=98you may call =E2=80=98exit=E2=80=99 but only if no = files (as in FILE*) are open=E2=80=99. >=20 > Best regards, > Maxime Devos >>You have lost me. "AC-safe" means async-cancel-safe. It is irrelevant: = [=E2=80=A6] Right, I meant AS-unsafe(=3Dasync signal safe). (but not AS-safe). >On Async-Signal Safety, whatever you may say, 'exit' is not on the POSIX list of async-signal-safe functions. See the POSIX standard of 2017, General Information, paragraph 2.4.3, Signal Actions: "Any function not in the above table may be unsafe with respect to signals." Do 'man 7 signal-safety', also at https://man7.org/linux/man-pages/man7/signal-safety.7.html, to see your implementation's list, which includes '_exit' but not 'exit' (on my distribution), thus conforming with POSIX. This explains the discrepancy: POSIX confusingly separates the AS-safety in= formation from the other documentation of the function. > AS-Safety is probably also irrelevant because as I understand it guile implements its own deferred signal delivery with asyncs, which may or not permit guile's exit to be invoked in an async handler (I have never examined it to find out). POSIX and glibc documentation is not authoritative on that. I wasn=E2=80=99t considering guile=E2=80=99s exit, I was considering C=E2= =80=99s exit, and under the assumption that it is AS-safe. Guile=E2=80=99s = =E2=80=98exit=E2=80=99 procedure is irrelevant here (and IIRC doesn=E2=80= =99t actually exist). Guile does not block all signals or install signal handlers for everything.= Hence, one of these could have a signal handler that is run as a POSIX sig= nal handler, and (under =E2=80=98exit=E2=80=99 is AS-safe assumption) runs = =E2=80=98exit=E2=80=99. Then the proposed Scheme exit hooks would be invoke= d, and could get in trouble (no malloc from within a signal handler, etc.). Best regards, Maxime Devos. --_796FB59E-0091-4FCA-BB42-5D7AE49C89DF_ Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"

On Thu, 7 Nov 2024 17:10:45 +0100

Maxime Devos <maximedevos@telenet.be&g= t; 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 run= s Scheme code, it could do a lot of

> >> AC-unsafe things, resulting in problems= .

> >>= ;

> >&g= t; (*) glibc documentation says =E2=80=98exit=E2=80=99 is AC-unsafe, but th= is 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 asy= nc-signal-safe (AS-safe).=C2=A0 'exit' is not a-s-s and

> >cannot be called in a si= gnal handler (for example it can flush buffers)

> >whereas '_exit' is a-s-s.=C2=A0 = Furthermore a registered handler cannot

> >itself safely call 'exit'. [=E2=80=A6]

>

> No, I did mean exa= ctly what I wrote. Read the glibc documentation of =E2=80=98exit=E2=80=99 a= nd you=E2=80=99ll see. (Likewise for the POSIX page for =E2=80=98exit=E2=80= =99 =E2=80=93 POSIX does not seem to restrict things to _outside_ signal ha= ndlers.)

> =

> Also, wh= en two authorative sources (POSIX and glibc in this case) have contrary cla= ims, then simply repeating one of those claim does not help at all, you wou= ld need to explain the cause of the discrepancy instead.<= /p>

>

> That =E2=80=98exit=E2=80=99 flushes= buffers does not imply that =E2=80=98exit=E2=80=99 is async-unsafe, altern= atives include buffer flushing being safe, =E2=80=98exit=E2=80=99 having it= s own implementation of flushing that is AC-safe, or =E2=80=98you may call = =E2=80=98exit=E2=80=99 but only if no files (as in FILE*) are open=E2=80=99= .

>

> Best regards,

> Maxime Dev= os

 =

>>You have l= ost me.=C2=A0 "AC-safe" means async-cancel-safe.=C2=A0 It is irre= levant: [=E2=80=A6]

 

R= ight, I meant AS-unsafe(=3Dasync signal safe). (but not AS-safe).

 

>On Async-Signal Safety, wh= atever you may say, 'exit' is not on the

POSIX list of async-signal-safe functions.=C2=A0= See the POSIX standard of

2017, General Information, paragraph 2.4.3, Signal Actions: &q= uot;Any

functi= on not in the above table may be unsafe with respect to

signals."=C2=A0=C2=A0 Do 'ma= n 7 signal-safety', also at

https://man7.org/linux/man-pages/man7/signal-safety.7.html, t= o see your

imp= lementation's list, which includes '_exit' but not 'exit' (on my=

distribution), thus conf= orming with POSIX.

 

Th= is explains the discrepancy: POSIX confusingly separates the AS-safety info= rmation from the other documentation of the function.

=

 

> AS-Safety is probably also irrelevant= because as I understand it guile

implements its own deferred signal delivery with asyncs= , which may or

not permit guile's exit to be invoked in an async handler (I have never

examined it to f= ind out).=C2=A0 POSIX and glibc documentation is not

<= p class=3DMsoNormal>authoritative on that.

 

I wasn=E2=80=99t considering guile= =E2=80=99s exit, I was considering C=E2=80=99s exit, and under the assumpti= on that it is AS-safe. Guile=E2=80=99s =E2=80=98exit=E2=80=99 procedure is = irrelevant here (and IIRC doesn=E2=80=99t actually exist).

 

Guile does not block all signals or i= nstall signal handlers for everything. Hence, one of these could have a sig= nal handler that is run as a POSIX signal handler, and (under =E2=80=98exit= =E2=80=99 is AS-safe assumption) runs =E2=80=98exit=E2=80=99. Then the prop= osed Scheme exit hooks would be invoked, and could get in trouble (no mallo= c from within a signal handler, etc.).

 

<= span lang=3DEN-GB>Best regards,

<= span lang=3DEN-GB>Maxime Devos.

<= span lang=3DEN-GB> 

 

= --_796FB59E-0091-4FCA-BB42-5D7AE49C89DF_--