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: Sat, 28 Dec 2024 19:32:21 +0000 Message-ID: <87r05reh9t.fsf@protonmail.com> References: <87o713wwsi.fsf@telefonica.net> <87a5ch5z1b.fsf@gmail.com> <87plld5pev.fsf@protonmail.com> <87ed1t6r34.fsf@gmail.com> <875xn46s6z.fsf@gmail.com> <86bjwwulnc.fsf@gnu.org> <877c7jlxsu.fsf@gmail.com> <86frm7sx4d.fsf@gnu.org> <87a5cfoivh.fsf@gmail.com> 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="40707"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Eli Zaretskii , gerd.moellmann@gmail.com, ofv@wanadoo.es, emacs-devel@gnu.org, acorallo@gnu.org To: Helmut Eller Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Dec 28 20:52:36 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 1tRcrU-000ARf-Fe for ged-emacs-devel@m.gmane-mx.org; Sat, 28 Dec 2024 20:52:36 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tRcr7-00081c-Gb; Sat, 28 Dec 2024 14:52:13 -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 1tRcY2-0004fo-1i for emacs-devel@gnu.org; Sat, 28 Dec 2024 14:32:30 -0500 Original-Received: from mail-40133.protonmail.ch ([185.70.40.133]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tRcY0-0005Fj-H6; Sat, 28 Dec 2024 14:32:29 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1735414345; x=1735673545; bh=WqgiOeOjcbKloZ5pSGcqUqigCDx+7iQtHDdJff5sZsk=; 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=CLPK/E7vztAIMfaooEXGzdf9VBKd2RBBjIZ6cFTTfMWCVhGlQGG1X3emgxFepkO1H YrPrX/U6sNruGZJXtMZv8EWz1dloHPfQba7/vdMvAWhQkOkjEphBuXg5Ho31c97nVm wu0ejFn7xFxkh1nvUXzbECZbbJdRq0uRt2AKvKNjBHBnFHmViRp85FNkCbyHEuT3cU /aOyakoQfiiSh0G4bRSxS0mrXE605QhF0HHU0xgQW9PAMoRW9xF0fTVIIHiTn62R6Y yhzPomWpLRrZzbr2MFVizMDYA1lnjwAMn6Qb29Iw4utfyPYaNMKqQWZPQSUkvLXegP n4OTvjUzned0Q== In-Reply-To: <87a5cfoivh.fsf@gmail.com> Feedback-ID: 112775352:user:proton X-Pm-Message-ID: d1dacc57a9fb05e9b12a0a507ff31f9890b42758 Received-SPF: pass client-ip=185.70.40.133; envelope-from=pipcet@protonmail.com; helo=mail-40133.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_H3=0.001, RCVD_IN_MSPIKE_WL=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: Sat, 28 Dec 2024 14:52:12 -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:327296 Archived-At: "Helmut Eller" writes: > On Sat, Dec 28 2024, Eli Zaretskii wrote: > >> I'm thinking about a situation where SIGPROF was delivered while it >> was blocked. In that case, it will be re-delivered once we unblock >> it. >> >> By contrast, if we avoid delivering SIGPROF in the first place, it >> will never be delivered until the next time SIGPROF is due. >> >> So imagine a function FUNC that conses some Lisp object. This calls >> into MPS, which blocks SIGPROF, takes the arena lock, then does its >> thing, then releases the lock and unblocks SIGPROF. If SIGPROF >> happened while MPS was working with SIGPROF blocked, then the moment >> SIGPROF is unblocked, the SIGPROF handler in the main thread will be >> called, and will have the opportunity to see that we were executing >> FUNC. By contrast, if the profiler thread avoided delivering SIGPROF >> because it saw the arena locked, the next time the profiler thread >> decides to deliver SIGPROF, execution could have already left FUNC, >> and thus FUNC will not be in the profile. >> >> I hope I made myself more clear this time. > > 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 which aren't being delayed) would not be able to access MPS memory, which I thought was the goal. Pip