From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Ihor Radchenko Newsgroups: gmane.emacs.devel Subject: Re: MPS: a random backtrace while toying with gdb Date: Sun, 30 Jun 2024 21:08:48 +0000 Message-ID: <87plry6sv3.fsf@localhost> References: <87bk3jh8bt.fsf@localhost> <87wmm6rcv1.fsf@gmail.com> <86le2mhhsj.fsf@gnu.org> <875xtqramd.fsf@gmail.com> <86cynyhfsn.fsf@gnu.org> <87v81qp91g.fsf@gmail.com> <86tthafbix.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="6994"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Helmut Eller , gerd.moellmann@gmail.com, pipcet@protonmail.com, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Jun 30 23:08:05 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 1sO1mH-0001aE-0Z for ged-emacs-devel@m.gmane-mx.org; Sun, 30 Jun 2024 23:08:05 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sO1lc-0002SI-Sl; Sun, 30 Jun 2024 17:07:24 -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 1sO1lZ-0002Rf-AH for emacs-devel@gnu.org; Sun, 30 Jun 2024 17:07:21 -0400 Original-Received: from mout01.posteo.de ([185.67.36.65]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sO1lW-00078h-Au for emacs-devel@gnu.org; Sun, 30 Jun 2024 17:07:21 -0400 Original-Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id 9CB4A240028 for ; Sun, 30 Jun 2024 23:07:15 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1719781636; bh=s0UEJp2xIKTVIom2cS+uNKXsxgXoAWhz6imBJJTGZLw=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type: From; b=ru/tgQdt1gF1E9zBF5/2nOwRSi2nnOFy4Nuwl50JhsetF4yrysexTajxpANc4Pbcy 63PMHVZIoDK/crqh/AJMCS5zDtd94iu6oCHme0mPuvFmw0GSGBro60fLtgcTQ/bWE3 VCeNPFH/kKI26o5LtFqvqH60bgA5Al3KDYtNGWWrHeuLnVVwheOjvCV+5O2MUYRyWw ZO6X0tIidUFVFgZnu7qzs75zyxA3FYdq55+rCMhzEMwa41x5Y0DOCMnyOwnnC+cijY R5op/kLtAMn5H7/XtiEU/ELrCmx60IpLHVyYjwRpSoTAkMHXtCewnFrqRwm6LlCytN sBP7dCr+FunKg== Original-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4WC1vk5SJDz6tyY; Sun, 30 Jun 2024 23:07:14 +0200 (CEST) In-Reply-To: <86tthafbix.fsf@gnu.org> Received-SPF: pass client-ip=185.67.36.65; envelope-from=yantar92@posteo.net; helo=mout01.posteo.de X-Spam_score_int: -43 X-Spam_score: -4.4 X-Spam_bar: ---- X-Spam_report: (-4.4 / 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, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=unavailable autolearn_force=no X-Spam_action: no action 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:320986 Archived-At: Eli Zaretskii writes: > Frankly, if this is what we must do, then this branch is not very > interesting. Too bad, I thought this was a promising development in > Emacs. What about going back to the alternative proposal with setting up signal masks: Eli Zaretskii writes: >> From: Pip Cet >> ... >> 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. I am looking at https://memory-pool-system.readthedocs.io/en/latest/topic/thread.html#thread-interface And it says that In a multi-threaded environment where incremental garbage collection is used, threads must be registered with the MPS by calling mps_thread_reg() so that the MPS can suspend them as necessary in order to have exclusive access to their state. If my understanding is correct, the situation we have is when MPS is performing root scan while also receiving another signal. During the root scan, all other Emacs threads are suspended, and no state changes are taking place - everything is locked by MPS thread, which is the only thread running. Emacs signal handlers are, of course, installed for all the threads. And since the only thread being running is MPS thread - it will be the one handling the received signal. And the handler thus cannot run normally, reaching out to the MPS-managed memory as usual. So, we should somehow arrange the handler to wait until the MPS scan finishes and the actual Emacs threads are resumed. Such waiting should not lose any information as the actual Emacs state is not going to change during the scan. The simplest way to do it is setting up a mask for MPS thread. (Although, we may or may not want to do it for profiler signals specifically, depending on whether these signals will be queued by the OS or merged into a single signal before unblocking - merging will make us loose some samples) -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at , or support my work at