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: Some experience with the igc branch Date: Mon, 23 Dec 2024 15:07:37 +0000 Message-ID: <87ttaucub8.fsf@protonmail.com> References: <87o713wwsi.fsf@telefonica.net> <87ldw7fwet.fsf@protonmail.com> <87a5cnfj8t.fsf@protonmail.com> <86seqe4j4f.fsf@gnu.org> 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="16652"; 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: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Dec 23 17:36:23 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 1tPlPr-00046n-GF for ged-emacs-devel@m.gmane-mx.org; Mon, 23 Dec 2024 17:36:23 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tPlPO-0004ru-MY; Mon, 23 Dec 2024 11:35:54 -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 1tPk2D-00057i-Ne for emacs-devel@gnu.org; Mon, 23 Dec 2024 10:07:53 -0500 Original-Received: from mail-10631.protonmail.ch ([79.135.106.31]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tPk2B-0003yb-0B; Mon, 23 Dec 2024 10:07:53 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1734966463; x=1735225663; bh=9xcoKd73Ia701mYgpq1RS/gVRo+5AdIMq6/kfl5nco4=; 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=g5xOCR54Uoi4Qz+mUnYvnEh0hIa7kzUw+qNbHtxxlLzTzWhCzAV9QcvuWt6UH2a42 bjLUIPEI7sgW8ptG1Atx4fMgYAUMAm4rKJCdrBZ7h3yPN/QY2nwLyVl1m+oFkIhD6Z gMjoD9ytCBQUFH1hUMcIzdFHFR0N+kRfnXPSSCiMcpA/knLC/hHrm4GgA9Fss6bPiL YTY3pZmWj//G/eHr9OzSSxL36cmFY2xqAH4bo2lqUzyl3VaLKQ1x72Aq6qZVpXQkgr eIH0EQjaNG7EZG1YC8BOi96DV4uS5cqFoAVEhflQJ774WYSJk4YBhaOmFP1iF8f7IE ff6VZMwewWc9A== In-Reply-To: <86seqe4j4f.fsf@gnu.org> Feedback-ID: 112775352:user:proton X-Pm-Message-ID: 32a75a855729f8b7644330c714cebd572b5f5ef7 Received-SPF: pass client-ip=79.135.106.31; envelope-from=pipcet@protonmail.com; helo=mail-10631.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_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_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: Mon, 23 Dec 2024 11:35:47 -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:326918 Archived-At: "Eli Zaretskii" writes: >> Date: Sun, 22 Dec 2024 22:26:11 +0000 >> Cc: =C3=93scar 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 Because... > call some code from a signal handler, so the limitations that MPS > seems to impose now are not very reasonable. Maybe we are missing ...if they were interested, maybe they've read this or some other blanket accusation of being "unreasonable", and became uninterested quickly. I know I would. > 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. I have a different idea using a separate allocation thread (for the slow path only, of course). Would that be potentially acceptable? It would limit MPS to systems providing a working atomic.h header, and in practice also require some sort of working (and reasonably fast) inter-thread signalling (though I suspect it'd be faster to run both threads on the same core, since it's a handover rather than a parallelism situation). That excludes very few systems these days (sorry, MS-DOS). I'll spare you most of the details for now, but having read the mps header, MPS allocation is not safe to use from separate threads without locking the AP (or having per-thread APs), which we might end up doing on Windows, IIRC. I'd rather give those (potential) issues a wide berth. Also, by the campsite rule, merging MPS shouldn't make it harder to move in the direction of multi-threaded Emacs. Better debugging (which I agree with you is something we need to improve), no MPS modification. Performance implications TBD. > 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. Agreed. Pip