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: Sun, 29 Dec 2024 12:15:41 +0000 Message-ID: <87o70ud6to.fsf@protonmail.com> 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> 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="21480"; 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 Sun Dec 29 14:34:21 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 1tRtQy-0005Oe-7v for ged-emacs-devel@m.gmane-mx.org; Sun, 29 Dec 2024 14:34:20 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tRtQC-00008o-6I; Sun, 29 Dec 2024 08:33: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 1tRsD7-0006H2-Bi for emacs-devel@gnu.org; Sun, 29 Dec 2024 07:16:00 -0500 Original-Received: from mail-10630.protonmail.ch ([79.135.106.30]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tRsD3-0004E5-EE; Sun, 29 Dec 2024 07:15:56 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1735474545; x=1735733745; bh=a+ojQwhBC+GKtcIjNZw9+upjdl9yK1NTt1ytB31eWs4=; 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=i8+nX0tpy1kDDXi2XANGOqbvulHQZr6ognhQ7t/beY+g6Wxzmo0Ch+2SAwftIFR9E cAx2XFsw85CFbohLv8S0JgEXqHQqDlFXnFrjhqcCDdZAp1OmzWnvMRuNQ6yVGRuEKZ M3BLPYHNzGFQkJefDEz98swgXaAl4mfGLfMJlFDrWb3Wfjw9etrFZsLSCG2z3zgRnv P08GFhTlGPoQw3E4FuZIcgl99/seTMunqr0S0W/qeBPU5XhEtLM7PpwancfzhVHSxi aIuV9uA0VZW7Kk3yhancj/L5cM2gLGma/Ttz8I6jzKBgWhyp//8IUmcpXD4J5JFTSG m4ZjgJV4SuFAg== In-Reply-To: <86ttanqc0p.fsf@gnu.org> Feedback-ID: 112775352:user:proton X-Pm-Message-ID: 98d3f07f06e26dbad419b4db6cbb0e5d983c3a0e Received-SPF: pass client-ip=79.135.106.30; envelope-from=pipcet@protonmail.com; helo=mail-10630.protonmail.ch X-Spam_score_int: -10 X-Spam_score: -1.1 X-Spam_bar: - X-Spam_report: (-1.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, FREEMAIL_REPLY=1, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-Mailman-Approved-At: Sun, 29 Dec 2024 08:33:23 -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:327334 Archived-At: "Eli Zaretskii" writes: >> Date: Sat, 28 Dec 2024 20:43:18 +0000 >> From: Pip Cet >> Cc: Eli Zaretskii , gerd.moellmann@gmail.com, ofv@wanadoo.= es, emacs-devel@gnu.org, acorallo@gnu.org >> >> "Helmut Eller" writes: >> >> > On Sat, Dec 28 2024, Pip Cet wrote: >> > >> >>> I think I see what you mean. I imagine the profiler thread to be a = loop >> >>> like >> >>> >> >>> while (true) { >> >>> sleep () >> >>> ArenaEnter () >> >>> pthread_kill (SIGPROF, ) >> >>> wait () >> >>> ArenaLeave () >> >>> } >> >> >> >> I'm not really following. Did you mean to include a call to a "clear >> >> all memory barriers" function after the ArenaEnter call? If not, the >> >> SIGPROF handler (and all handlers interrupting the SIGPROF handler wh= ich >> >> aren't being delayed) would not be able to access MPS memory, which I >> >> thought was the goal. >> > >> > In my mind it works like this: when the SIGPROF handler tries to acces= s >> > MPS memory, the SIGSEGV handler kicks in as it usually would in a >> > non-signal handler context. This should work because at the beginning >> > of the SIGPROF handler we guarantee that MPS doesn't hold the arena >> > lock. >> >> Sorry, still not following. The SIGPROF-sending thread holds the arena >> lock. So we can't take it in the SIGSEGV handler. It's still a >> deadlock, right? > > But the SIGPROF handler doesn't take the arena lock, it starts by > writing to the pipe, which then causes the SIGPROF-sending thread to > release the lock, thus letting the SIGPROF handler touch memory which > could trigger MPS into taking the lock. Thanks, I got the idea now! Yes, that would work, assuming SIGPROF is never blocked, and that no signal interrupting the SIGPROF handler attempts to take the arena lock. (Also, we assume the SIGPROF handler has finished by the time the next SIGPROF is sent. I think this assumption is fixable, though, and we'd need to fix it for other signals). Pip