From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: =?utf-8?Q?Gerd_M=C3=B6llmann?= Newsgroups: gmane.emacs.devel Subject: Re: igc, macOS avoiding signals Date: Mon, 30 Dec 2024 12:53:33 +0100 Message-ID: References: <799DDBC5-2C14-4476-B1E0-7BA2FE9E7901@toadstyle.org> <86ed1rswup.fsf@gnu.org> <87h66loc17.fsf@gmail.com> <878qrxoayj.fsf@gmail.com> <8734i5o6wc.fsf@gmail.com> <87cyh9mpn5.fsf@gmail.com> 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="36756"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: Eli Zaretskii , spd@toadstyle.org, pipcet@protonmail.com, emacs-devel@gnu.org To: Helmut Eller Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Dec 30 12:54:10 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 1tSELY-0009TC-VG for ged-emacs-devel@m.gmane-mx.org; Mon, 30 Dec 2024 12:54:09 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tSEL7-0004WZ-KD; Mon, 30 Dec 2024 06:53:41 -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 1tSEL5-0004WH-DB for emacs-devel@gnu.org; Mon, 30 Dec 2024 06:53:39 -0500 Original-Received: from mail-ej1-x62c.google.com ([2a00:1450:4864:20::62c]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1tSEL3-0000OL-MZ; Mon, 30 Dec 2024 06:53:39 -0500 Original-Received: by mail-ej1-x62c.google.com with SMTP id a640c23a62f3a-aa692211331so1747332966b.1; Mon, 30 Dec 2024 03:53:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1735559615; x=1736164415; darn=gnu.org; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=Fe4Eee12sXDq9ibtOitlODPSKk3MOPcKcMPCllKKK/o=; b=LElBw44TpMH97wyL1OG8wBobxWdWYBQY8tOt/owsGZ87vE5kTQI2Tb5eePPSEtZicP kdmrWM+6e5K8ZgoPBbNu96yHGzykJ0yq2lxN69BskxrFKpI1fgmduDIp1Qky8n4+qFL3 X9xcilwaZpYzhu8yCUyzX/mJYwbK8gcqrpyZA/8zM9+/NdyU1/OIQ9jzGJ0RVjI46as0 Zueu10C2jBik04J6NnsMJ3+pAqXQbT6o62CRqwtii34MPPQHO39MikWsUsx0XeHXPq0p j+S/bIpMNU0ljnJ3ge33JeItSTgbO5zm/RO0QWxTC4ugcs7MKj+OGGNX8R9wgvweSkGJ ksdw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1735559615; x=1736164415; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=Fe4Eee12sXDq9ibtOitlODPSKk3MOPcKcMPCllKKK/o=; b=SPeRMuEWlg0bOJv9qMlFYLsDioN8nTYlgD8tBEs40Cqaa2Oy4N+uS9zW7jX96TPMZY JnwXGBpepPphXp9lVNgsIDQf6hOhi6CI7s9fv7KxD3IpgpQqSa+GJG+vp3GFNvuZtPZ0 9UyVRPiZg3JL/6Of/gzE1l1SQ8rfLHxQqV/51AzM54Bwu7y/PRnoXPqAGFsgD5Bp8Lqs B9tfyCTb/8aIKkzq2jAxpUOUNzC1JH5lRl0XjGRQxKekXb5vt3amjJHI44KIFKcC6+Hj 9cOOZ7YbSMrmu4jufA/l+y2necbBrX833KrquSOhVtQIy8w0ZIC+ZvejQ5cwUfQ4FlAY V6Ig== X-Forwarded-Encrypted: i=1; AJvYcCUGzG8oQdHophqLfr6eQFbNxjFXbVAHAqs5ndp29TFVnqccVpTAE12H4Ir92kxYv+5BRpW+7qiQofmKyw==@gnu.org X-Gm-Message-State: AOJu0YyFxvdmk/8lXzMdbPNtvPG32k0Ug4p2LFpUOBVrIw08meSyNTyO EpwYfK7bzGDlI1lKw7hgUZMwm803/+quNoVvii674xy0teWXh+mRLu8R0g== X-Gm-Gg: ASbGnctUVQsntXN9X9cdWGcC5OYSFeiVljjLt9LNyGHWWajRPWs48Oe1wGQmy3tDWWd NBC8e/L5gUG1i0QcHbrCb0cE9y74RNPYgdoPJu2vFN2+PlZIUWKF1KYm+ew3ViLr50Eg3QTk/1x WFS0Zc3X6WqXU6vT1xMHqVoBBJtBBCIira7E4W87OTWo7Bt0auMA6G65+hsjJ5G7kgHMp155btu +npvNobZPscYQyIbD8Id+AWyFnDNAdT5MgqLuH3cY0tBb29X1MjgPfkHXw/IlMlBeMMT8PUxjXz 7aSghYdlAHNFnebax1uCtP/3GSdiwfV8DYE/JUBfSpaCUcQo6lXu0uwXuz8Yknsx X-Google-Smtp-Source: AGHT+IENsXV5GDdj71GEJzUkbrw4GFTKiZS9RNznX+qCufZV1L6JfEsHwdXg6pr30ibxwv4Oos7ahA== X-Received: by 2002:a17:907:704:b0:aa6:489e:5848 with SMTP id a640c23a62f3a-aac34695112mr3031136066b.25.1735559615026; Mon, 30 Dec 2024 03:53:35 -0800 (PST) Original-Received: from pro2 (p200300e0b7156f000dceccb84ca1ba38.dip0.t-ipconnect.de. [2003:e0:b715:6f00:dce:ccb8:4ca1:ba38]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-aac0e894c2esm1485975166b.67.2024.12.30.03.53.34 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 30 Dec 2024 03:53:34 -0800 (PST) In-Reply-To: <87cyh9mpn5.fsf@gmail.com> (Helmut Eller's message of "Mon, 30 Dec 2024 11:27:58 +0100") Received-SPF: pass client-ip=2a00:1450:4864:20::62c; envelope-from=gerd.moellmann@gmail.com; helo=mail-ej1-x62c.google.com 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_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: 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:327402 Archived-At: Helmut Eller writes: > On Mon, Dec 30 2024, Gerd M=C3=B6llmann wrote: > >>> My interpretation of this design document[*], is that MPS's arena lock >>> protects most of MPS entry points. There are a few (e.g. mps_reserve >>> and mp_ld_add) that don't claim the arena lock and for those it's the >>> burden of the client to call them in a thread safe way. For us this >>> probably means: don't call them in a signal handler. >>> >>> The main entry point that we want to call in the signal handler is the >>> SEGFAULT handler (not sure how this works on MacOS). The fault handler >>> claims the non-recursive arena lock. So, in the signal handler we >>> should not hold the lock while hitting a barrier. >> >> Okay, that I think I understand then. The "only" difference between >> macOS and Linux is that on macOS no SEGV handler is involved. Hitting >> the barrier on macOS means that the EXC_BAD_ACCESS port thread, which >> was waiting for Mach message, receives a message from the OS and starts >> working. > > I guess that both, macOS and Linux version, will end up in ArenaAccess. > Perhaps on macOS in the other thread. > >>>> I think I understand that, except when the Emacs thread is interrupted >>>> while in MPS code, which happens for allocation points running out of >>>> memory and mps_arena_step (idle time). >>> >>> Hmm, is that sentence incomplete? I don't quite understand it. >> >> What I meant is that I imagine a signal interrupts the Emacs thread at a >> point where we are "in MPS". AreaEnter/Leave I think I understand, it's >> some pthread_mutex_t, I think, from other mails. A problematic "in MPS" >> could then be "while the Emacs thread owns the mutex". The places where >> I imagine that mutex could be owned are mps_arena_step (I call it Emacs >> is idle) and mps_commit (in alloc_impl, when the allocation point used >> runs out of memory). Maybe other places, but mainly these two. > > Yes. > >> And the question on macOS for me would be if the port thread tries to >> qcquire the same mutex, or how the heck that works. Or IOW, if there is >> a problem, why I've never seen it happening in all that time I'm using >> igc. > > Maybe you could set a breakpoint in AreaAccess to find out which thread > removes the barriers. > >> I find that difficult to understand. But it may be just a >> statistical phenomenon. Maybe filling up an APs memory is so fast so >> that the probability of a signal hitting while owning the mutex is close >> to zero, or something. > > Very few of Emacs' signal handlers actually touch a barrier. I've also > not seen any reproducable receipes for the "signal issues" that the igc > branch supposedly has. > > Helmut I've got something, using Eglot/clangd. Executive summary: If a signal interrupts the Emacs thread, and we are "inside MPS", meaning the Emacs threads owns an arena's mutex, the macOS port thread can try to acquire the same mutex and won't get because the Emacs thread that owns it is stopped by the signal. It goes like this: ** mps_commit mps_commit -> mps_ap_trip -> ArenaEnter ** ArenaEnter ArenaEnter -> ArenaEnterLock non-recursive -> LockClaim arena lock -> pthread_mutex_lock. -> ShieldEnter -> shieldQueueReset Sets some members of a Shield, .inside =3D true ** MPS port thread protCatchThread -> mach_msg waiting -> protCatchOne thread involved has been stopped by OS -> ArenaAccess -> arenaClaimRingLock -> LockClaimGlobal -> LockClaim globalLock (static LockStruct) -> RING_FOR uninteresting macrology -> ArenaEnter for the 1 arena we have ** Global lock (uninteresting here) LockInitGlobal -> LockInit globalLock -> LockInit globalLockRecLock -> pthread_mutex_init with no interesting attrs Sp, I'd say - It's possible to freeze on macOS because of hitting a barrier, or allocating Lisp objects. I don't believe that I would have overlooked something preventing it. - It's apparently very unlikely to happen, for me at least it never happened in, don't know, half a year or so of daily usage. Maybe one could make it happen when profiling for long enough. - Only signal handlers are affected, and what you said about signal handlers using Lisp and so on. Hm.