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 19:47:36 +0200 Message-ID: <86ikr1njuv.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> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="1419"; 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 Mon Dec 30 18:49:19 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 1tSJtG-0000Bq-Ax for ged-emacs-devel@m.gmane-mx.org; Mon, 30 Dec 2024 18:49:18 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tSJsX-0001t8-OG; Mon, 30 Dec 2024 12:48:34 -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 1tSJsV-0001rY-TE for emacs-devel@gnu.org; Mon, 30 Dec 2024 12:48:31 -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 1tSJsU-0007lU-AR; Mon, 30 Dec 2024 12:48:30 -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=jSnYS/rQvC7l81mDkf6Mil7oqoP6nZPS86MQ7QCJDsQ=; b=I3ObIOcdlyjz CFVp5kwdyaw6mxwPieQlLy2DG3fWey4K4AMchEvqoOjtv9rfBlCIMXfvhwLqlpT9U7p9PYjuwycFz 2l5eSSCQNuB14S4dIQuJN7ZICUZzvo2TR0PGTxmwXWe7netXaSz4yz2+PY0ESbQE1DUwEleewufkv vi/cQn43i6kVa/jgLMDlxwftmzcZRfwFxxkB+PCVLLROTBz3pgUnufTnMrwuCc3Ie8tTieoTCubj2 s9lvLBZheLLzsPleiMfdOkShoUMx0CUXMW08eRIg2GpokkliWe1SwX2tzsyIyMCKjkXumdstMPAAM w+znn3NbUETPdkgq/YpcdA==; In-Reply-To: <87seq5xgpt.fsf@protonmail.com> (message from Pip Cet on Mon, 30 Dec 2024 16:46:20 +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:327455 Archived-At: > 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. > We shouldn't avoid it because we want signal handlers to be called > in signal handler context, not as C functions. Actually, no, we have no problems running the handlers we have as C functions. Again, the MS-Windows build does that for years. > > . signal handler is called > > . if the arena is unlocked, it runs the handler's body > > (BTW, if we're going for POSIX-conforming solutions, we can't call > pthread_mutex_trylock in a signal handler. We do it today, because that's how MPS crashes us. So yes, we can do that. > > . otherwise, it sets a flag to indicate the signal happens and exits > > Which retriggers the signal No, it doesn't. Again, we already have signals whose handlers behave like that. > > - when the arena is unlocked, we are called, and run the handler's body > > Do you mean "run the handler's body" or "try again"? I'm not sure > running it unconditionally is safe, so I'd prefer to "try again", > re-establishing a signal handler context by unblocking the signal and > re-killing the main thread (even if that's us). I see no reason why it would be unsafe to just run it. Again, our handlers are simple and usually do very little (SIGCHLD is a possible exception, but we already have a solution for it, AFAIU). > We can't run another thread's signal handler. Not in general, but in practice in Emacs we can (and do). > Again, I think this is a good idea, but I'd use it as an improvement to > the current protection code, not to replace it. 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.