From: Maxime Devos <maximedevos@telenet.be>
To: Mailer <vine24683579@gmail.com>, guile-devel <guile-devel@gnu.org>
Subject: RE: [PATCH] At-exit hook
Date: Thu, 7 Nov 2024 17:10:45 +0100 [thread overview]
Message-ID: <20241107171045.ZsAk2D00S42S6aw01sAkk9@laurent.telenet-ops.be> (raw)
In-Reply-To: <20241107120925.87d4b80c9f289d18eec437ad@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1486 bytes --]
On Thu, 7 Nov 2024 12:23:08 +0100
>Maxime Devos <maximedevos@telenet.be> wrote:
>> ‘atexit’ functions are run at ‘exit’. ‘exit’ 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 ‘exit’ is AC-unsafe, but this is
>> unsupported by POSIX AFAICT. OTOH the same applies to even ‘malloc’,
>> so likely I’m 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'. […]
No, I did mean exactly what I wrote. Read the glibc documentation of ‘exit’ and you’ll see. (Likewise for the POSIX page for ‘exit’ – POSIX does not seem to restrict things to _outside_ signal handlers.)
Also, when two authorative sources (POSIX and glibc in this case) have contrary claims, then simply repeating one of those claim does not help at all, you would need to explain the cause of the discrepancy instead.
That ‘exit’ flushes buffers does not imply that ‘exit’ is async-unsafe, alternatives include buffer flushing being safe, ‘exit’ having its own implementation of flushing that is AC-safe, or ‘you may call ‘exit’ but only if no files (as in FILE*) are open’.
Best regards,
Maxime Devos
[-- Attachment #2: Type: text/html, Size: 3846 bytes --]
next prev parent reply other threads:[~2024-11-07 16:10 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-06 19:52 [PATCH] At-exit hook Mikael Djurfeldt
2024-11-07 11:23 ` Maxime Devos
2024-11-07 12:08 ` Nala Ginrut
2024-11-07 12:09 ` Mailer
2024-11-07 12:27 ` Mailer
2024-11-07 13:28 ` Mikael Djurfeldt
2024-11-07 16:10 ` Maxime Devos [this message]
2024-11-07 19:51 ` Mailer
2024-11-07 22:18 ` Maxime Devos
2024-11-08 9:09 ` Mikael Djurfeldt
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=20241107171045.ZsAk2D00S42S6aw01sAkk9@laurent.telenet-ops.be \
--to=maximedevos@telenet.be \
--cc=guile-devel@gnu.org \
--cc=vine24683579@gmail.com \
/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).