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 17:03:08 +0200 Message-ID: <86pll9nrgz.fsf@gnu.org> References: <87o713wwsi.fsf@telefonica.net> <86bjwwulnc.fsf@gnu.org> <877c7jlxsu.fsf@gmail.com> <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> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="17181"; 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 16:04:07 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 1tSHJP-0004Kc-8k for ged-emacs-devel@m.gmane-mx.org; Mon, 30 Dec 2024 16:04:07 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tSHIp-0001LH-SA; Mon, 30 Dec 2024 10:03:31 -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 1tSHIo-0001L8-Vu for emacs-devel@gnu.org; Mon, 30 Dec 2024 10:03: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 1tSHIm-0006rB-NX; Mon, 30 Dec 2024 10:03:28 -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=fa8f+gajFmBUkISFAG+Wtv4KPRYANP+AkjdAirAvwUM=; b=Aa8sCJPuJGqo vTg0NSgqznLTRKsgttd/mtBvye3P45pguaqyInE6fbpkMSkIfgJUxJxdSkqIZ6hpLtmsHViDrmTzJ KS+qrbf3UxCgglzJT/lmXbZPt4bFwS9TNGSELFzCjHHk45vtTE0jUz5DfDGbk9/2liUrptEn6ZvlT 6f5psDQnaN/BAcdpjdRP4KhvLNHeob2D+lWYp4Ys2zAZPfrgUhsJ+JU34IxgM9sYzYhgCNMQUDaaD iYAn6T8uzyQBygceB8S+JpByE6HZVilMGANab44ENkyp2ljcdv2CmVn3EBDHeBPLFBDX04xSU8Zl5 HnK+p91avdD2zfOAb5QZgw==; In-Reply-To: <87bjwu2pb6.fsf@protonmail.com> (message from Pip Cet on Sun, 29 Dec 2024 20:44:07 +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:327435 Archived-At: > Date: Sun, 29 Dec 2024 20:44:07 +0000 > From: Pip Cet > Cc: eller.helmut@gmail.com, gerd.moellmann@gmail.com, ofv@wanadoo.es, emacs-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, just much simpler and without the need to have a separate thread, re-killing, etc. IOW, the idea is: . signal handler is called . if the arena is unlocked, it runs the handler's body . otherwise, it sets a flag to indicate the signal happens and exits - when the arena is unlocked, we are called, and run the handler's body Does this do the same as what you wanted to achieve? > 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?