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 16:46:20 +0000 Message-ID: <87seq5xgpt.fsf@protonmail.com> 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> 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="28004"; 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 Mon Dec 30 18:34:35 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 1tSJf0-00077Z-S6 for ged-emacs-devel@m.gmane-mx.org; Mon, 30 Dec 2024 18:34:34 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tSJef-0004tR-Fy; Mon, 30 Dec 2024 12:34:15 -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 1tSIuV-0003xq-Uj for emacs-devel@gnu.org; Mon, 30 Dec 2024 11:46:35 -0500 Original-Received: from mail-4322.protonmail.ch ([185.70.43.22]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tSIuR-0001EB-PH for emacs-devel@gnu.org; Mon, 30 Dec 2024 11:46:31 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1735577184; x=1735836384; bh=xAc4rtNcnMZNTd46CJPCqNwTEfhtLxRxrrENdo90n9o=; 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=LGU7zseY7ATrmq/oT5FvGf7Swy327+tRXGb3EXhSbrwNsYwFaNDfOPug/SiNN6iTR q2ZXfrRzCf9Kiq6oIserkC2TnIVlI8J1BDfE0IzVqi5QZFh9Fs/KUUCGmfpBEuk0DT LTZwjcPPiRVKbXLVd0dO/LZzLnG8J8YXbl6o958xZJRbvXAMAUQxTJ4RQoBa+UOfoy tSD+ldfesT6c6WIHWxak+VfRh7EMWAIVrruGCUIRBD3jogWd3t/SWLCkXoj30t07tU 6hcqlFiTKiAlsEN3Q/puuZRy9jGygA2lalY8Uwx307y2BdCEd69EHIeb5I4cmDGBjH lq8btZrLTHqGw== In-Reply-To: <86pll9nrgz.fsf@gnu.org> Feedback-ID: 112775352:user:proton X-Pm-Message-ID: abfdfa0065d2ea8d2298b920e313e00dc5a05c1a Received-SPF: pass client-ip=185.70.43.22; envelope-from=pipcet@protonmail.com; helo=mail-4322.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 12:33:38 -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:327452 Archived-At: "Eli Zaretskii" writes: >> Date: Sun, 29 Dec 2024 20:44:07 +0000 >> From: Pip Cet >> Cc: eller.helmut@gmail.com, gerd.moellmann@gmail.com, ofv@wanadoo.es, em= acs-devel@gnu.org, acorallo@gnu.org >> >> Here's a sketch. The idea is that all signals go through the signal >> receiver thread, which serializes them, picks one, enters the arena, >> tells the main thread that this signal is now safe to run, re-kills the >> main thread, waits for confirmation, leaves the arena, waits for >> confirmation AGAIN, then goes back to sleep. > > Is the "enters the arena, tells the main thread that this signal is > now safe to run" part so that we avoid the recursive arena lock, which > leads to crashes? If so, having MPS implement a callback immediately > after it releases the arena lock will provide us with the same device, This is a bit complicated, so let's refer to the code currently on scratch/igc as (1), and the proposed signal receiver thread as (2). ((3), again, no longer in the picture). The summary is that would be a useful MPS modification (and one which I didn't have in mind as a possible improvement! Thanks!) which wouldn't complicate our code by much, but wouldn't allow us to make it any simpler, either. That MPS modification WOULD be useful, but it wouldn't make (1) any simpler, AFAICT. It might allow us to improve (1), at the cost of some complication, to the point (2) would no longer be a useful option. The callback could happen on any thread, or even in a signal handler. On macOS, it could happen in the exception thread, which isn't set up to receive or handle signals. > just much simpler and without the need to have a separate thread, > re-killing, etc. IOW, the idea is: We can't avoid re-killing because we might be on another thread. We shouldn't avoid it because we want signal handlers to be called in signal handler context, not as C functions. > . 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. This is relevant because if we assume we can call that, we might as well use pthread_cond_broadcast in a signal handler, which avoids the "Ouch" we discussed yesterday: there's no need for a separate thread for reading from a pipe and translating that into a pthread_cond_broadcast call. But, again, that's (3), which is on medical leave for now and not expected to rejoin the workforce.) > . otherwise, it sets a flag to indicate the signal happens and exits Which retriggers the signal in the case of "level-triggered" signals such as SIGCHLD, inflooping us. (Yes, SIGCHLD is a special case which might be handled differently. I have no idea whether there are other such signals, TBH. I just know that if I implemented the idea you described, it wouldn't work without special-casing SIGCHLD). So we need to block the signal here, I think. > - when the arena is unlocked, we are called, and run the handler's bo= dy 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). We can't run another thread's signal handler. But, oops, we can't unblock the signal if we're not on the right thread, so then we need the SIGURG code from (2) after all, or we need to rely on the existing code from (1) for handling that case. > Does this do the same as what you wanted to achieve? I think having such a callback would be a worthwhile improvement to the code currently on scratch/igc, and potentially avoid the need for signal serialization. Importantly, it would not be required: if we don't have the new MPS callback, the code on scratch/igc will work fine, but cause occasional delays. If we don't want the SIGURG code, we can simply accept that those few signals that are affected get delayed a little. As I've said, we'd need a shadow signal mask, though. The reason for that is that there's no "blocked" counter: blocking a signal twice and unblocking it once will leave it unblocked. >> However, the re-kill cannot happen just with the same signal, because we >> need to block that in the main thread, in the case of SIGCHLD > > Didn't Gerd and/or Helmut already solve the SIGCHLD case by moving its > handler's body out of the signal handler? It's possible SIGCHLD is the only signal that's weird in this way. I don't know (SIGURG, in its intended function?). Even if SIGCHLD is the only level-triggered signal, maybe there are others that are retriggered at a high frequency until we run their handlers (SIGALRM?). I'm not sure whether there are useful SIGBUS handlers these days... 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. Pip