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: Fri, 27 Dec 2024 11:36:43 +0000 Message-ID: <87plld5pev.fsf@protonmail.com> References: <87o713wwsi.fsf@telefonica.net> <87ttaucub8.fsf@protonmail.com> <87pllicrpi.fsf@protonmail.com> <864j2u442i.fsf@gnu.org> <87a5ch5z1b.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="9482"; mail-complaints-to="usenet@ciao.gmane.io" Cc: =?utf-8?Q?Gerd_M=C3=B6llmann?= , Eli Zaretskii , 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 Fri Dec 27 13:24:58 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 1tR9Ok-0002JP-H4 for ged-emacs-devel@m.gmane-mx.org; Fri, 27 Dec 2024 13:24:58 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tR9O7-0000Hm-3X; Fri, 27 Dec 2024 07:24:19 -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 1tR8eQ-0007Ga-5E for emacs-devel@gnu.org; Fri, 27 Dec 2024 06:37:07 -0500 Original-Received: from mail-40131.protonmail.ch ([185.70.40.131]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tR8eN-0000ff-J1 for emacs-devel@gnu.org; Fri, 27 Dec 2024 06:37:05 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1735299409; x=1735558609; bh=OkfLTlL1+2s/Xx92zf+E2fpYzZ080z6ywyY+tWN9P60=; 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=yBkjmuUrUwahRqPhei5wHg0ZHrv6y/bbb0SFkslYp8Stf2H6zwCEA7GtL/lBeJoz6 ZmnYCia31lrH4mdwtm+yaezKBbgSs9cMAWk8zWyqeDsSprvkWOdB5/hCT7OkEjO2fR HrPRdhNXt+vgoHG5rBWZpwUGmNy0oT5WHtCNzCaF0Cp/ykCf5Tvs/sq2IgJlRPd7Oc 9yVC7sEKYKFZGLKZvBAljATbduF5+GFgyJhGFt/Shecs8bkpq0iSEE9hluOwShYKnI 0oOY50B/R/06aBj79DYPs7f+X8+SmLd0jBe69+JQKiHqMKCso/znzHbkj88udonQcH ZLdGYQ5JEBvvg== In-Reply-To: <87a5ch5z1b.fsf@gmail.com> Feedback-ID: 112775352:user:proton X-Pm-Message-ID: 8b260ae12bdfbab9652956175fd8e80d4399bceb Received-SPF: pass client-ip=185.70.40.131; envelope-from=pipcet@protonmail.com; helo=mail-40131.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: Fri, 27 Dec 2024 07:24:07 -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:327185 Archived-At: "Helmut Eller" writes: > On Tue, Dec 24 2024, Gerd M=C3=B6llmann wrote: > >>> I've looked at SIGPROF. From an admittedly brief look at this, I'd >>> summarize my results as: >>> >>> - The important part is get_backtrace. The rest could be done elsewhere >>> by posting that to a message board, or whatever the mechanism is at >>> the end. > > I have an idea how to make a safer profiler. First, remember that MPS "Safer" how? > will stop mutator threads to protect its own consistency. What happens > if we make the profiler its own thread? MPS will stop the profiler like > normal mutator threads. This is useful and is as it should be. If we tell MPS about it, it'll be stopped, yes. > The problem now is how the profiler thread can do what get_backtrace > does. We can use a protocol between the profiler thread and the main > thread that goes like this: > > 1. The profiler periodically sends a signal, say SIGPROF, to the main > thread. > > 2. In the signal handler for SIGPROF, the main thread synchronizes > itself with the profiler by communicating over a pipe (like the Unix > fathers did it). It sends some token to the profiler and waits. ...forever, if the profiler thread has been suspended at this point. > 3. The profiler receives the token and can now access the virtual > machine state because the main thread waits. The profiler now does > what get_backtrace does. After logging the stack snapshot, the > profiler sends the token back to the main thread > > 4. The main thread receives the token, returns from the signal handler, > and continues execution. > > Note that the signal handler only communicates over the pipe and doesn't > read or write any memory that could mess up MPS. The profiler thread > doesn't run any signal handlers (other than those that MPS may use > behind the scenes). Can you explain how this would produce different behavior than what we have currently, apart from the deadlock? I'm sorry, but it's not obvious to me. If the main thread was performing GC when SIGPROF arrived, the SIGPROF handler cannot do get_backtrace, and the profiler thread can't, either. > Another observation: MPS sends SIGXFSZ and SIGXCPU to stop and resume > threads. We could intercept those signals and block SIGPROF while the > thread is stopped. Obviously a hack, but could still be useful. MPS blocks all signals (except for the wakeup signal) while threads are suspended. This is suboptimal behavior and not something we should expect and rely on. Pip