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: a random backtrace while toying with gdb Date: Mon, 01 Jul 2024 21:31:58 +0300 Message-ID: <86bk3hdkv5.fsf@gnu.org> 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> <87plry6sv3.fsf@localhost> <86le2lfjqv.fsf@gnu.org> <87jzi5ibbe.fsf@localhost> <864j99fg0a.fsf@gnu.org> <87msn18225.fsf@localhost> <86le2ldn2t.fsf@gnu.org> <87h6d97zzm.fsf@localhost> <86frstdlla.fsf@gnu.org> <87ed8d7yy3.fsf@localhost> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="5339"; mail-complaints-to="usenet@ciao.gmane.io" Cc: eller.helmut@gmail.com, gerd.moellmann@gmail.com, pipcet@protonmail.com, emacs-devel@gnu.org To: Ihor Radchenko Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Jul 01 20:32:57 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 1sOLph-0001BY-CW for ged-emacs-devel@m.gmane-mx.org; Mon, 01 Jul 2024 20:32:57 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sOLop-0001Wg-Kf; Mon, 01 Jul 2024 14:32:03 -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 1sOLoo-0001WR-Bn for emacs-devel@gnu.org; Mon, 01 Jul 2024 14:32:02 -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 1sOLon-0004uV-B2; Mon, 01 Jul 2024 14:32:01 -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=ftbymVOaVb6qR4hLN9YdglXz6gS7Mh8G9XaJ4eU+rB8=; b=hqQ8C61BnU4u ZFNox5akWO8n3Pa+oE/8IUKaLiqaP36n/PfH5dvV+qhAcezXXBc0n+JyfkapOKCCpZVNlYuBW1Ln8 BlK4//6CeoRpEhhFc0OeMd05fcNXepTinksei/OI4c/HHp2YLFWq86ebFrIrvywfrNd2zOqFECAsQ FVx2kcKUNOt5ikngdF99RQ703qOv70XLKOy8xOUl/Vy/AYVP3NTM/tiMhwQB6lMfReRaZjhVCLgPz 9psngIV+ZjvekVXwHa3nVJSTOnCNTx+rOnZP3MlDuYCwbCKhCSgOZOJ4U2EpgzPZaC0WOpQ0y5NuQ B5I4UjSrPW0E33yGcahd1g==; In-Reply-To: <87ed8d7yy3.fsf@localhost> (message from Ihor Radchenko on Mon, 01 Jul 2024 18:24:20 +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:321054 Archived-At: > From: Ihor Radchenko > Cc: eller.helmut@gmail.com, gerd.moellmann@gmail.com, pipcet@protonmail.com, > emacs-devel@gnu.org > Date: Mon, 01 Jul 2024 18:24:20 +0000 > > Eli Zaretskii writes: > > >> I do not mean calling malloc. I mean, what happens if a signal arrives > >> _while_ malloc is still in the process of allocating data? > > > > That's what I mean by "you mean malloc". > > > > If a signal happens while malloc is in progress, it is not a problem, > > because signal handlers should not re-enter malloc. > > So, maybe it is going to be enough to make sure that we block signals > while running `alloc_impl' (in igc.c)? Something like that. I'm not familiar enough with the MPS functions we call in igc.c, but blocking signals should be done around any calls that could take the arena lock. > > And if that doesn't answer your question, maybe I don't understand > > what is it exactly that you are asking. > > I was mostly asking about technical implementation details of how malloc > is preventing signals from being handled while it is doing its > job. It doesn't. It's the responsibility of the signal handlers not to re-enter malloc. We cannot do the same with MPS, because MPS can kick in outside of our control -- for example, if accessing some Lisp object hits the barrier. So we have no idea when MPS will take the arena lock, and this cannot prevent recursive locks, except by preventing our code which touches Lisp data from running when MPS is active because we called it. To say this in different words: MPS must be in control of all the threads which can touch the data it manages, and code that runs from a signal handler is a kind-of separate thread, except that we have no way of registering such a thread with MPS as we do with real threads.