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: SIGPROF + SIGCHLD and igc Date: Mon, 30 Dec 2024 21:04:34 +0000 Message-ID: <875xn0rihm.fsf@protonmail.com> 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> 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="32025"; 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: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Dec 31 04:21:52 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 1tSSpL-00088x-Av for ged-emacs-devel@m.gmane-mx.org; Tue, 31 Dec 2024 04:21:51 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tSSoe-00055Z-RS; Mon, 30 Dec 2024 22:21:09 -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 1tSMwS-0007pH-36 for emacs-devel@gnu.org; Mon, 30 Dec 2024 16:04:48 -0500 Original-Received: from mail-40131.protonmail.ch ([185.70.40.131]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tSMwN-0003ie-Pm for emacs-devel@gnu.org; Mon, 30 Dec 2024 16:04:47 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1735592680; x=1735851880; bh=CVKzH8jtOGceuN2IgZ5aaOVXh4uDbxxsD+UDNx+/f6Q=; 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=TvUI26GfintlV3GGvHtL3UQ7/T4Q2gSPvAI0zl6fKz4Q/2h5olGjU7lNUko+qTdX6 Fj39G7T7GP1/9ufi8eqVa/fHSVn2BZqPug2mNgdDnbFcs33i6Jx9PIbMNb2+Qr0pl4 Wa263bQ8mpfYzMBYOpM83XhRiTX9BlOtCfBqDIww1OsuUjH1+iJ5l7W6h3ixnb3qFo gBirNnRLqknOplaeDJnWsdDa9xDM7c8Hf73xo99Q6O1tgkgCMmX528jSE0U1Ov7rPf hzL2r5pVtPbONabBJfW4d9xP6W6haipqbBg4iHDf7xmcWV/xiYRz2kcg8WZBp84tvO 1aIxjN1cBwTEw== In-Reply-To: <86ikr1njuv.fsf@gnu.org> Feedback-ID: 112775352:user:proton X-Pm-Message-ID: 2f6b05b36f28b368cfeeae8c54301d0efb39705f Received-SPF: pass client-ip=185.70.40.131; envelope-from=pipcet@protonmail.com; helo=mail-40131.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_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-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=unavailable autolearn_force=no X-Spam_action: no action X-Mailman-Approved-At: Mon, 30 Dec 2024 22:21:01 -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:327471 Archived-At: "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, em= acs-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, which continues to mutate Lisp data. I'm pretty sure we don't do that on Windows (where we make use of the non-POSIX feature of suspending threads, I hope); if we do, it'll cause weird crashes. Half-written EMACS_UINTs are the least of our problems there: if SIGPROF doesn't freeze the specpdl, it will read dangerously incorrect data. I don't think this approach works for any signal that we can't simply special-case in our current code. 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. (I also don't think all is well with Emacs. We need to improve its stability, not use its existing imperfections as an argument that reducing stability is okay.) All that said, signals are on their way out, and have been for a while. It's unlikely we'll see exciting new signal handlers, and very likely that we will stop using some of the existing ones (GNU/Linux doesn't require SIGALRM or SIGPOLL/SIGIO, since it can poll fds efficiently. SIGSEGV is already handled differently, more like macOS does it, on some Linux kernels used in Android systems (which is good for us); SIGCHLD is, I think, being replaced by process fds); or, at least, simplify them in all Emacs branches. I'm not aware of a compelling reason to do anything but improve the current code incrementally. Radically different approaches have been tried; some work, some don't, those that do work have severe disadvantages. In the end, it's just signals. It's important they work and work correctly, but if you're receiving them at high rates you should look at non-signal solutions. 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. 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). Pip