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: Mon, 30 Dec 2024 20:25:24 +0200 Message-ID: <86cyh9ni3v.fsf@gnu.org> References: <87o713wwsi.fsf@telefonica.net> <86frm7sx4d.fsf@gnu.org> <87a5cfoivh.fsf@gmail.com> <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> <5A733BD6-6077-4705-B9BB-B465859D3F2C@dancol.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="18115"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org, pipcet@protonmail.com, eller.helmut@gmail.com, gerd.moellmann@gmail.com, ofv@wanadoo.es, acorallo@gnu.org To: Daniel Colascione Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Dec 30 19:26:33 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 1tSKTJ-0004ai-OH for ged-emacs-devel@m.gmane-mx.org; Mon, 30 Dec 2024 19:26:33 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tSKSK-0002CG-Mh; Mon, 30 Dec 2024 13:25:32 -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 1tSKSG-0002Bu-OD for emacs-devel@gnu.org; Mon, 30 Dec 2024 13:25:29 -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 1tSKSF-00048m-FJ; Mon, 30 Dec 2024 13:25:27 -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=Db4ZhOqTcr1E9xOB4YkCkFiaehsb9en+31OGonX5+LA=; b=WDHQdx/aKObu Fu/c9wd8942wdVQeRM/r+bZSvblFYYNRswoB3C0mk5SAo4l0tDn9ToxqfvsPYDr7rrFe02EZs2+HO UVc9D3Wl28Ja+31LcWYUG0VR50DOVGWmJlY0WeO22QdlzBS8U0aM1fN7+k3tgFdJql0eC3kBQb1o7 U5FCouqBfEHB8J2DUaMU2NQ8hDKOBS+s4MFgQaPgdB7j5NSVJ/EDSM4TFvnYXeIThSSVqty1n8Rw7 rE16yQkvK4v4LEsSGWkDLYiTjqLg01q4mwoA0X6TVvPr5xz5Sb+XlXtxtK+HX7KDyiOdRKkbFbjtu S+QXGLkSNGKCrPwaxdJYJA==; In-Reply-To: <5A733BD6-6077-4705-B9BB-B465859D3F2C@dancol.org> (message from Daniel Colascione on Mon, 30 Dec 2024 12:53:49 -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:327459 Archived-At: > Date: Mon, 30 Dec 2024 12:53:49 -0500 > From: Daniel Colascione > CC: eller.helmut@gmail.com, gerd.moellmann@gmail.com, ofv@wanadoo.es, > acorallo@gnu.org > > >I think you are over-complicating things because you are looking for a > >110% waterproof solution that would work for arbitrary code in the > >handler. But we don't need such perfection, as the existing practices > >show. > > > > The code there TODAY might not need to be "waterproof", but someone might add logic one day that violates the unstated simplifying assumptions on which you're relying. In this case, we'll end up with subtle and hard to diagnose race conditions. Better to make the mechanism robust from the start. Trying to take shortcuts with POSIX signals is penny wise and pound foolish. I agree with the ideal, but if it makes things too complicated, then I prefer simpler solutions together with vigilance to prevent dangerous code from entering our codebase. Experience shows that we are quite capable of doing that, since we've been doing that for many years. Excessive complications in the design and implementation also come with risks, as we all know. I'd rather we avoided too many extra threads, cross-locking, re-signaling, and other such stuff if we can.