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: MPS: profiler Date: Fri, 21 Jun 2024 14:09:41 +0300 Message-ID: <86iky2lfgq.fsf@gnu.org> References: <87v823xvq1.fsf@localhost> <86plsalgot.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="38105"; mail-complaints-to="usenet@ciao.gmane.io" Cc: yantar92@posteo.net, emacs-devel@gnu.org, gerd.moellmann@gmail.com, eller.helmut@gmail.com To: Pip Cet Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Jun 21 13:10:41 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 1sKcAC-0009X4-Cx for ged-emacs-devel@m.gmane-mx.org; Fri, 21 Jun 2024 13:10:40 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sKc9N-0000Va-NQ; Fri, 21 Jun 2024 07:09:49 -0400 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 1sKc9M-0000VH-Az for emacs-devel@gnu.org; Fri, 21 Jun 2024 07:09:48 -0400 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 1sKc9K-0000le-8r; Fri, 21 Jun 2024 07:09:46 -0400 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=iJOOo+5VR7hJa/7qwL8Y1a0oFbsBYzeFid+ur3OmKIc=; b=qupaIbWzmkyE zeRrq4Rx6WfnF3yA2SSiGkprW5Otb9TJYJ5Laxi/5pZm+thGOPyPLFjXV/Fn8mFsMT5qCDctiOT7b VbdlrwfyxbVhR4UWO/h/u4Ybz28ZbrlKaeBOicKz4jFZATR1dhGl4XzXNCBX9LR/15p6po0FZainL kUdqbyB0nqySg558ubR5cu+GC4SxzEh6LGDHr+dnxHWMUB2oKTKsIZzzxTQJ4IziL2oo9d0jOWFi8 R9JbYW43IF+4ULYUhUXblF0NshplbEnwnlwLpTfriYifVy5lJvKGGuYwD+AQQGyhTDB4wUN4rkKGY FmjCt5OFV8+aziN+LW11mQ==; In-Reply-To: (message from Pip Cet on Fri, 21 Jun 2024 11:00:02 +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:320388 Archived-At: > Date: Fri, 21 Jun 2024 11:00:02 +0000 > From: Pip Cet > Cc: yantar92@posteo.net, emacs-devel@gnu.org, gerd.moellmann@gmail.com, eller.helmut@gmail.com > > > > The right thing to do, IMHO, is to let MPS know that it should block SIGPROF (and any other signals that might use managed memory) while handling SIGSEGV. > > > > I disagree. MPS must be able to support programs compiled with > > "-gprof", so I don't believe SIGPROF should be blocked. > > Only while handling SIGSEGV, of course. > > > The handler > > is our code, so we should modify the handler not to do anything unsafe > > if SIGPROF happens while MPS is processing its SIGSEGV. That's a much > > more reliable fix, and one that will allow us to keep our profiling > > code. > > Why are you suggesting that my "fix" (which, yes, is overly broad, we'd need to go through the signals to find all we can safely leave unblocked) requires any changes to the profiling code? As far as I can tell, it just works. > > The main difference between the two approaches, both of which require meddling with MPS internals, is that if SIGPROF is blocked, it will be delivered with a delay after the SIGSEGV handler is done running. If the SIGPROF handler runs and doesn't do "anything unsafe", on the other hand, it can record the unusable signal but won't get a new one. I don't see a clear advantage of either, to be honest. Blocking signals, of course, is more reliable than "just knowing" we won't do anything unsafe. I simply don't believe MPS is so poorly designed as to disallow signals while its own SIGSEGV handler runs. SIGPROF is just one example; there are also SIGALRM, SIGUSR1, SIGUSR2, and maybe others. It makes little sense to me to expect MPS to block these signals. I rather expect them to DTRT with those signals. My first suspect is our own code. Until we establish positively that our code is fine, and what happens here is that we hit the MPS protection in our SIGPROF handler, I don't think we should consider changes in the MPS code.