From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Mailer Newsgroups: gmane.lisp.guile.devel Subject: Re: [PATCH] At-exit hook Date: Thu, 7 Nov 2024 19:51:57 +0000 Message-ID: <20241107195157.5a8cad633d4370bf4c48f21f@gmail.com> References: <20241107122308.ZnP72D00T42S6aw01nP8co@laurent.telenet-ops.be> <20241107120925.87d4b80c9f289d18eec437ad@gmail.com> <20241107171045.ZsAk2D00S42S6aw01sAkk9@laurent.telenet-ops.be> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="9769"; mail-complaints-to="usenet@ciao.gmane.io" To: guile-devel Original-X-From: guile-devel-bounces+guile-devel=m.gmane-mx.org@gnu.org Thu Nov 07 20:51:29 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 1t98XR-0002G0-BK for guile-devel@m.gmane-mx.org; Thu, 07 Nov 2024 20:51:29 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1t98Wg-0000LL-A8; Thu, 07 Nov 2024 14:50:42 -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 1t98We-0000L2-RF for guile-devel@gnu.org; Thu, 07 Nov 2024 14:50:40 -0500 Original-Received: from mail-ed1-x52e.google.com ([2a00:1450:4864:20::52e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1t98Wc-0002hc-VH for guile-devel@gnu.org; Thu, 07 Nov 2024 14:50:40 -0500 Original-Received: by mail-ed1-x52e.google.com with SMTP id 4fb4d7f45d1cf-5ceb03aadb1so1575705a12.0 for ; Thu, 07 Nov 2024 11:50:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1731009036; x=1731613836; darn=gnu.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:to:from:date:from:to:cc:subject:date:message-id :reply-to; bh=osmaEL2g+Vds0O7rYV02aC5fIwj47pHjYSDEq/4MIBk=; b=ER/GURAiEIXvEefjEltzrqQjgn6rQFQkaLHePRQUz8Bn7QqXWNOAqxsN3qTkangtG4 GrSTLfhyRQx5y65f+khv0SJgru7Kq+w1AWNu/+BdgliB+FOiLgWt8fHvO3SPaUbQAu+0 /eXIF2+Utre8H/+vwPZWFxGrnyVuojLjGEZzyMECE06tfCHBrtDSBRFOINw34C4UVRji 02l5GMIzjO9ZXQsqlEl5ZBYGJLql8UwqYv3rv9jddDM0Q1mqiGXgBJXLuDW2JX0n7zCa //4X201H9YJ07cfA94kB61YQ0crL1RIrWzzEiJGHACCqdrtaCb29Xbso0cZLr2A29GEw iXgw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1731009036; x=1731613836; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:to:from:date:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=osmaEL2g+Vds0O7rYV02aC5fIwj47pHjYSDEq/4MIBk=; b=ff6ljcT84rqMneFH+Fmz4S2OEuv4/5C/G9WX5nsSMkQLZd4z9nmJI9vAj5u9zULUYJ 5twCgINsORdwVo4wv94mlJB/3XvLWulAZPRx5BwKOJxXFNof3sJG9mSuKTNRRF/5bAsb IUNhrRazZ+fvvB4YO/+7GijSTMq49BiJpyrIVu7eKk3QhbyHHsSo0ByFItK61TnE5spg o3qeB/uW0S0rJ3yT/hQbCR+Vp5ZsqKPb/Bg5gf4m59whwzFoax/X5dFU5U5YO0hdP3mr eX0p6iSBT68ttgjRqIh3nhZBbq9p16KnhQ10mtCJn/xZKeX1aXCkmaWi0s172WeVnIbN H31Q== X-Gm-Message-State: AOJu0Yxn5XJhLGF/78krPfO1K3Kcy7YVnOBlRDLQ6lBw0DQ9lvp9KdvE h9q9k+j0AaIOrtrFuNM+Jnn65oD/sJBvuSxbbuL8DGoBkIZyevBziS7f7Q== X-Google-Smtp-Source: AGHT+IEXYOKFHKXwfaRvcI3Dd1w7Z08hnmsc7jrOs/e4/tBIWuvsOwOM3p1UnEGC6aVVNu6lkR/+4A== X-Received: by 2002:a05:6402:5241:b0:5ce:d02e:c964 with SMTP id 4fb4d7f45d1cf-5cf0a31b5b0mr79556a12.11.1731009036121; Thu, 07 Nov 2024 11:50:36 -0800 (PST) Original-Received: from bother.homenet ([2.24.141.99]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-5cf03c4ed9fsm1163544a12.62.2024.11.07.11.50.35 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 07 Nov 2024 11:50:35 -0800 (PST) Original-Received: from bother.homenet (localhost [127.0.0.1]) by bother.homenet (Postfix) with SMTP id 8057A266613 for ; Thu, 07 Nov 2024 19:51:57 +0000 (GMT) In-Reply-To: <20241107171045.ZsAk2D00S42S6aw01sAkk9@laurent.telenet-ops.be> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; x86_64-unknown-linux-gnu) Received-SPF: pass client-ip=2a00:1450:4864:20::52e; envelope-from=vine24683579@gmail.com; helo=mail-ed1-x52e.google.com X-Spam_score_int: -43 X-Spam_score: -4.4 X-Spam_bar: ---- X-Spam_report: (-4.4 / 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_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, NICE_REPLY_A=-2.588, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=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:22766 Archived-At: On Thu, 7 Nov 2024 17:10:45 +0100 Maxime Devos wrote: > On Thu, 7 Nov 2024 12:23:08 +0100 > >Maxime Devos 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 You have lost me. "AC-safe" means async-cancel-safe. It is irrelevant: 1. Only three POSIX functions are async cancelation safe, namely pthread_cancel, pthread_setcancelstate, and pthread_setcanceltype. See the POSIX standard of 2017 (the only one I have to hand), General Information, paragraph 2.9.5, Async-Cancel Safety: "No other functions in this volume of POSIX.1-2017 are required to be async-cancel-safe." The GNU documentation says the same. 2. No one ever uses asynchronous cancelation anyway, partly because of that. Deferred thread cancelation at safe cancelation points is the only cancelation used in practice. 3. AC-Safety has no bearing on the current discussion in any case. 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. 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. Chris