From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Pip Cet via "Emacs development discussions." Newsgroups: gmane.emacs.devel Subject: Re: igc, macOS avoiding signals Date: Tue, 31 Dec 2024 13:49:05 +0000 Message-ID: <87y0zwneuh.fsf@protonmail.com> References: <799DDBC5-2C14-4476-B1E0-7BA2FE9E7901@toadstyle.org> <87msgdkt29.fsf@gmail.com> <86h66lnjrt.fsf@gnu.org> <868qrxnfrw.fsf@gnu.org> <87a5ccl2zx.fsf@gmail.com> <87h66kfae5.fsf@gmail.com> Reply-To: Pip Cet Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="18561"; mail-complaints-to="usenet@ciao.gmane.io" Cc: =?utf-8?Q?Gerd_M=C3=B6llmann?= , Eli Zaretskii , spd@toadstyle.org, emacs-devel@gnu.org To: Helmut Eller Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Dec 31 15:15:50 2024 Return-path: Envelope-to: ged-emacs-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 1tSd2E-0004gU-0F for ged-emacs-devel@m.gmane-mx.org; Tue, 31 Dec 2024 15:15:50 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tSd1m-0005ll-4e; Tue, 31 Dec 2024 09:15:24 -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 1tSccX-0001wP-VZ for emacs-devel@gnu.org; Tue, 31 Dec 2024 08:49:18 -0500 Original-Received: from mail-10631.protonmail.ch ([79.135.106.31]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tSccW-0004jM-1Z for emacs-devel@gnu.org; Tue, 31 Dec 2024 08:49:17 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1735652950; x=1735912150; bh=kFGCDZCCC2m2SPGnJ5NGG79kPN0EROQ3yJDnSp3d8ig=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector:List-Unsubscribe:List-Unsubscribe-Post; b=vIt9ozoIcgi+6CwxI20mVkJwFMAJX35vUPn5L7L38YUFiGB2Njd/HV9RgOVO/dn4b nO76GyDIJONPeC9RyAZmfNpinPJl+ZOpHY3gR6RIoV25VwCmefEVuvZZJCna2OvMQK JLctbtbZCMYcYpOSoVxDn+LE80fyekN8eYmRpqkZjqw0B5BGjZTWmK5pJBt4rxdSpn r1Hcy1vhX8sm7jG+PnfxdeQ8umOOTPs6bERd9FVcuIG9MTuyAZwCAGixJyOXkB8Ogk qSQiX3NwN5gxTyLSQwrTLt+ZALiBdkFMxZJoGEb2ckZ2rb/yj+/LnrXUYaYyoVaflZ GiewocFeMO6tg== In-Reply-To: <87h66kfae5.fsf@gmail.com> Feedback-ID: 112775352:user:proton X-Pm-Message-ID: 32fca02875268fcba3f44c9e90faefdd4a83e554 Received-SPF: pass client-ip=79.135.106.31; envelope-from=pipcet@protonmail.com; helo=mail-10631.protonmail.ch X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 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, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Mailman-Approved-At: Tue, 31 Dec 2024 09:15:18 -0500 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:327504 Archived-At: "Helmut Eller" writes: > On Tue, Dec 31 2024, Gerd M=C3=B6llmann wrote: > >> Helmut Eller writes: > [...] >>> Except the POSIX police: it says that pthread_mutex_trylock isn't async >>> signal safe. I suppose this also makes it's unsafe to use MPS's fault >>> handler in an async signal handler. Bummer. (Does the police take >>> bribes?) > [...] >> So we have this picture, I think >> >> t1 t2 t3 >> ------------|------------|---------------------|-----------------> t >> signal pthread other stuff signal handler >> handler trylock until return to branching >> calling signal handler on result of busy >> mps_arena_ >> busy >> >> We have a window [t1, t2] where the nested signals lead to undefined >> behavior. and [t2, t3] where threads and nested signals can come into >> play, but that's not a problem, iff signal handlers don't leave a lock >> behind them. >> >> Hm. Have you perhaps looked at a pthread implementation, what such a >> mutex actually is on Linux? > > Judging from the source here > > https://sourceware.org/git/?p=3Dglibc.git;a=3Dblob_plain;f=3Dsysdeps/nptl= /bits/struct_mutex.h;hb=3DHEAD > > and here > > https://sourceware.org/git/?p=3Dglibc.git;a=3Dblob_plain;f=3Dnptl/pthread= _mutex_trylock.c;hb=3DHEAD > > I would say that the mutex is a struct with multiple fields and that > pthread_mutex_trylock is neither a syscall nor an atomic instruction. The PTHREAD_MUTEX_ERRORCHECK_NP case looks fine to me, assuming signal handlers balance successful trylock calls with unlocks in the same handler. It uses __data.__lock to serialize access to the plain old C data in the mutex struct, and doesn't touch anything if it can't acquire the lock atomically (that's what lll does). PTHREAD_MUTEX_RECURSIVE_NP, not so much, so don't use recursive mutexes :-) > The struct may simply be in an inconsistent state at the time t0, the > beginning of the SIGPROF handler. It could certainly be made to fail more loudly in the case of acquiring a recursive mutex from a signal handler. Someone might try to do that to build a non-recursive mutex based on recursive mutexes, but that's the only use case I can see. Alternatively, let's all switch to FreeDOS! No memory barriers, no signals, pdumper works now, and MPS just survived its first GC cycle. I said I wasn't going to port MPS to DOS, but I didn't have to; the ANSI C environment works fine, eagerly tripping all memory barriers rather than installing them. The real point of that experiment was to test whether the ANSI C environment might be a useful fire exit in case there are unfixable protection problems on some platforms. (It's true that most DOS "extenders" appear to use the MMU, and that might make it sound like mprotect() could simply involve walking the (unprotected) page tables; but my understanding is it's 4MB pages, which is inconvenient for us). Pip