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: SIGPROF + SIGCHLD and igc Date: Tue, 31 Dec 2024 14:35:14 +0200 Message-ID: <86y0zwm3nh.fsf@gnu.org> References: <87o713wwsi.fsf@telefonica.net> <87r05reh9t.fsf@protonmail.com> <87msgfmvrp.fsf@gmail.com> <87bjwvedzn.fsf@protonmail.com> <86ttanqc0p.fsf@gnu.org> <87bjwu2pb6.fsf@protonmail.com> <86pll9nrgz.fsf@gnu.org> <87seq5xgpt.fsf@protonmail.com> <86ikr1njuv.fsf@gnu.org> <875xn0rihm.fsf@protonmail.com> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="27065"; mail-complaints-to="usenet@ciao.gmane.io" Cc: eller.helmut@gmail.com, gerd.moellmann@gmail.com, ofv@wanadoo.es, emacs-devel@gnu.org, acorallo@gnu.org To: Pip Cet Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Dec 31 13:36:13 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 1tSbTp-0006tk-HC for ged-emacs-devel@m.gmane-mx.org; Tue, 31 Dec 2024 13:36:13 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tSbT0-0002nN-Ja; Tue, 31 Dec 2024 07:35:22 -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 1tSbSz-0002nD-F8 for emacs-devel@gnu.org; Tue, 31 Dec 2024 07:35:21 -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 1tSbSy-0000p8-R6; Tue, 31 Dec 2024 07:35:20 -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=fgupHSE1ItWxxyU3pQkcP642no6eIIu1XIHdTdQbGIU=; b=C5DZ5SOFROb9 AN7jYH6V2YxO6WshtPAqorkUx7oTuSSIXvtR//mMJqj6X1Q5nhi7U+dHJpggUK7UTMGraST54bae7 chKyxPohNwbQG3CsL3HLJHJ47ucq/ALBQpg27JCNe9HatEPsrzUbpCMInqEZHmrrELNxI3TuxXBM0 x0xEENqg8iufxYT95cHmhdszwTub4S5+3io4vOV/hhs4SKKlkWV4BUYDGfTzG17xlCNfVMyd7CzTk Ou9F7ahsdpdJJDipb7KTXa/so2w+wYAcGsB6HZkOwl8XfjHftVIkceGr07k7TkMXYjlWLpfQV/sOM YLF+heljlEowiDLSEKhQeA==; In-Reply-To: <875xn0rihm.fsf@protonmail.com> (message from Pip Cet on Mon, 30 Dec 2024 21:04:34 +0000) 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:327495 Archived-At: > Date: Mon, 30 Dec 2024 21:04:34 +0000 > From: Pip Cet > Cc: eller.helmut@gmail.com, gerd.moellmann@gmail.com, ofv@wanadoo.es, emacs-devel@gnu.org, acorallo@gnu.org > > "Eli Zaretskii" writes: > > >> Date: Mon, 30 Dec 2024 16:46:20 +0000 > >> From: Pip Cet > >> Cc: eller.helmut@gmail.com, gerd.moellmann@gmail.com, ofv@wanadoo.es, emacs-devel@gnu.org, acorallo@gnu.org > >> > >> We can't avoid re-killing because we might be on another thread. > > > > If we are on another thread, we know that, and can delay running the > > body. Or we could just run the body (all the signal handlers we have > > that I know about don't care: MS-Windows already does that). So this > > problem doesn't exist in practice, IME. > > Your (second) suggestion was to run the "signal handler" in parallel to > the main thread Yes. > which continues to mutate Lisp data. No. Doing that from a signal handler is a definite no-no, certainly if we call the handler from a non-Lisp thread. The only signal handler which currently does touch Lisp data, or comes close, is SIGCHLD. The MS-Windows emulation of SIGCHLD runs the handler synchronously (it is called from the emulated pselect); for Posix systems I believe we already have an alternative implementation on some branch which moves the body of the handler to the main thread. > I don't think this approach works for any signal that we can't simply > special-case in our current code. We only have 2 or 3 to worry about, and IMO we know enough about them to safely say that they all can (or already are) special-cased. > Throwing overboard working code > (which, yes, can be improved. Correctness first, though) to install a > solution that we know cannot possibly work, but relies on modifying MPS? > No. No, of course. But what you describe above is not the intent, at least not what I meant, and I don't believe anyone else in this discussion means anything like that. > I'm not aware of a compelling reason to do anything but improve the > current code incrementally. I think what's being proposed (by Helmut, mainly) is a move in that direction. > I still think we should decide whether we want a shadow signal mask > (which would allow us to check for pending signals much more often) and > whether we want to block some (most) signals while handling SIGSEGV, > reinstalling the MPS handler to do so. I'm thinking yes to both. Maybe, but let's discuss that after we have the basics of the modified handling of those 3 signals that will allow us to get rid of the crashes. > I'd also like a triple-quit-like mechanism for reacting to certain > signals in the event that we get stuck in MPS (as MPS has very few > bugs, it's most likely we're actually stuck in our own code called from > MPS). This will be important if we want people to trust the MPS branch > with their work, because it would sometimes allow recovery of such > sessions (data point: I just lost an email I was writing because I was > using the igc branch). You mean, the "emergency exit" feature? Yes, that should be very useful, but note that it cannot always succeed, because if you escape from GC, anything that allocates memory is living on borrowed time. And saving buffers generally must allocate memory. So it is not easy to make this reliable enough, it needs very careful programming and probably also some small reserve of memory ready to be used.