From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Some experience with the igc branch Date: Thu, 26 Dec 2024 11:32:06 +0200 Message-ID: <861pxuzt61.fsf@gnu.org> References: <87o713wwsi.fsf@telefonica.net> <864j2u442i.fsf@gnu.org> <87ldw6as5f.fsf@protonmail.com> <86o7112rnq.fsf@gnu.org> <867c7p2nz4.fsf@gnu.org> <861pxx2lh7.fsf@gnu.org> <86ldw40xbo.fsf@gnu.org> <86a5cj2a0e.fsf@gnu.org> <867c7n28sf.fsf@gnu.org> <877c7n962e.fsf@gmail.com> <8634ib24gp.fsf@gnu.org> <875xn75w7u.fsf@gmail.com> <86ttaryn1x.fsf@gnu.org> <877c7mzxbw.fsf@gmail.com> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="15660"; mail-complaints-to="usenet@ciao.gmane.io" Cc: gerd.moellmann@gmail.com, pipcet@protonmail.com, ofv@wanadoo.es, emacs-devel@gnu.org, acorallo@gnu.org To: Helmut Eller Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Dec 26 10:32:48 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 1tQkEZ-0003sn-Aq for ged-emacs-devel@m.gmane-mx.org; Thu, 26 Dec 2024 10:32:47 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tQkDz-0002ex-Tp; Thu, 26 Dec 2024 04:32:11 -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 1tQkDz-0002eo-5m for emacs-devel@gnu.org; Thu, 26 Dec 2024 04:32:11 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tQkDx-0008Gx-WB; Thu, 26 Dec 2024 04:32:10 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=gTwgMpbWxe2VQcipZ1DjOErjOrigtalp+WVuLKmkqtU=; b=pWz+2zhqKLPr 2XrW6xA9PayxKyVyqo6kxJGrXA7ZiRxIia3l5VXEm6taZCGRVQ0ZkU1cahmIERru4mw+xQiw6KrJq Ey9qRsEPNkkI/Cqwj+Us2jAh4kY8h9sN645GQyVzyEBtCHh2GR/yDh3yBCNNzjWLyVm0Vjricis1w tniKWgzc8nxmtT2LzmlW56Lg+WVzrQknhu360G4z3KTPNgaKCL7Th4XwfQJmS2ZKe50gIeZj1aXFp mitN/doOncDVHVJLqwnZi2SK3/hYPmc3SnQjo16uvGsHsslJEZqORUGOiiq4CeQafJGgGpTPqktyD dxTeueK33twN/R4UFH3ptA==; In-Reply-To: <877c7mzxbw.fsf@gmail.com> (message from Helmut Eller on Thu, 26 Dec 2024 09:02:11 +0100) 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:327142 Archived-At: > From: Helmut Eller > Cc: gerd.moellmann@gmail.com, pipcet@protonmail.com, ofv@wanadoo.es, > emacs-devel@gnu.org, acorallo@gnu.org > Date: Thu, 26 Dec 2024 09:02:11 +0100 > > On Thu, Dec 26 2024, Eli Zaretskii wrote: > > >> Your position is that blocking SIGPROF while MPS holds the lock is > >> the correct thing to do, right? > > > > Yes, I think so. (If you disagree, please tell why, and let's discuss > > that.) It is certainly a relatively simple thing to do. > > I quite like Pip's proposal of re-installing the SIGSEGV handler with an > additional sa_mask argument to block other signals. That would be nice > because a) we can do that without changing MPS and b) it's likely more > efficient than callbacks. Are we sure doing so will solve the problem? AFAIU, MPS can take the lock before SIGSEGV is delivered, or without its being delivered at all, isn't that so? (Besides, the sa_mask way won't work on Windows, which doesn't have sigaction and its emulation currently ignores sa_mask; we'd need to extend the emulation, but that will still leave a small window where the other signals are not immediately blocked after SIGSEGV.) > It would still be nice to simplify some signal handlers, like > handle_interrupt_signal, but with other signals blocked for SIGSEGV, it > would all be quite independent of MPS. Maybe. What bothers me more is whether the signals are delivered only to the main thread or to other threads. AFAIU, this behavior is system-dependent, and currently we seem to rely on the fact that the signals is delivered to the main thread. Given that we have other threads, including the MPS thread, I'm not sure we have this figured out. > > It is also possible for MPS to somehow manage an attempt to take the > > lock which is already held in a smarter way, by stopping the code > > which does that until MPS releases the lock. For example, MPS could > > define a protocol for such situations not unlike the GIL protocol we > > use for Lisp threads. But that's much more complex, and I don't > > necessarily expect the MPS folks to go to such lengths. > > I think that mps_arena_busy, which tests whether MPS holds the lock, is > quite adequate for the SIGPROF handler. It lets us detect the situation > and increment some counter. I'd like to have MPS folks confirm that. The documentation of this function seems to say we shouldn't use it "normally", only for debugging (so perhaps in some commands in .gdbinit). And see also this warning in their docs: Warning: This function only gives a reliable result in single-threaded programs, and in multi-threaded programs where all threads but one are known to be stopped (as they are when the debugger is decoding the call stack in the use case described above). AFAIU, Emacs doesn't fulfill the condition they define. Also, the code we currently have on the branch doesn't just "increment some counter", it flatly blocks the signal. For these reasons, I'm not happy with our current usage of that function for this purpose.