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: Some experience with the igc branch Date: Mon, 23 Dec 2024 15:35:44 +0200 Message-ID: <86seqe4j4f.fsf@gnu.org> References: <87o713wwsi.fsf@telefonica.net> <87ldw7fwet.fsf@protonmail.com> <87a5cnfj8t.fsf@protonmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="14966"; mail-complaints-to="usenet@ciao.gmane.io" Cc: gerd.moellmann@gmail.com, ofv@wanadoo.es, emacs-devel@gnu.org, eller.helmut@gmail.com, acorallo@gnu.org To: Pip Cet Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Dec 23 14:36:40 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 1tPibw-0003ht-Fe for ged-emacs-devel@m.gmane-mx.org; Mon, 23 Dec 2024 14:36:40 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tPibT-0004pM-Da; Mon, 23 Dec 2024 08:36:11 -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 1tPibN-0004oq-6T for emacs-devel@gnu.org; Mon, 23 Dec 2024 08:36:06 -0500 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 1tPibL-0008IP-Gi; Mon, 23 Dec 2024 08:36:03 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=jbAlcEB3nenzvR8yzb0t37J2vbOETkYMbUlZyxzkGRg=; b=LL+bmeswnf4b1xIEpw9E csd8y8YFuBxPa4zvBHYwwJuXsiMPILvpEsWkTf/5Kh+r4dV4UPTWBTDQ9gWZpgNNfFdumrTid00eV AWu7lQ4EH6PA8fkaV9tnGupYFqhT8i5/2wdWqltDgwUBXPdoo56UKT0LwHc7Fq5xYXfzSLh6LQLHi GFnifTTlsENTZitt2oroWWfPEZUBadgx/d9KhhgQ7wfYqIqhWwVE739eVkjT6q8Orevtr5PQ755NR 0k5JIxlQc/72sOKfSg8w8JrZEbLLTJ7uu4eO702UOPcpSsb/Iz23ylDGx0TpI+EytmSKKP5LuqtMo b3BSXTLxcbl6Ow==; In-Reply-To: <87a5cnfj8t.fsf@protonmail.com> (emacs-devel@gnu.org) 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:326904 Archived-At: > Date: Sun, 22 Dec 2024 22:26:11 +0000 > Cc: Óscar Fuentes , emacs-devel@gnu.org, > Helmut Eller , Andrea Corallo > From: Pip Cet via "Emacs development discussions." > > >> 1. The signal issue. I don't have a good way to fix this and make > >> everyone happy, but I do have a solution which hasn't caused a crash for > >> me in quite a while. It may be good enough. > > > > TBH, I'd have put it in already. > > Pushed it now. It is imperfect, but better than crashing. Why didn't we discuss this with MPS folks? A program can legitimately call some code from a signal handler, so the limitations that MPS seems to impose now are not very reasonable. Maybe we are missing some feature, or maybe the MPS folks will agree to extend the library to provide better support for programs that use signals. E.g., AFAIU with this code installed, we are limiting our profiler too much (it will never report GC, IIRC?). I think igc_busy_p returns non-zero in too many situations where delivering signals could not possibly cause harm, like during object allocation, AFAIR. According to documentation, that function is not intended for this kind of purpose. IOW, we had discussions about this which never concluded anything, and we should pick up where we left off and solve this problem. We should definitely try improving this before we land the branch on master. We shouldn't consider this solution "good enough", but just a temporary kludge meant to avoid too frequent crashes.