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: Tue, 24 Dec 2024 10:25:38 +0000 Message-ID: <87bjx1bcp8.fsf@protonmail.com> References: <87o713wwsi.fsf@telefonica.net> <86seqe4j4f.fsf@gnu.org> <87ttaucub8.fsf@protonmail.com> <87pllicrpi.fsf@protonmail.com> <864j2u442i.fsf@gnu.org> <87ldw6as5f.fsf@protonmail.com> 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="17643"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Eli Zaretskii , ofv@wanadoo.es, emacs-devel@gnu.org, eller.helmut@gmail.com, acorallo@gnu.org To: =?utf-8?Q?Gerd_M=C3=B6llmann?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Dec 24 12:59:26 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 1tQ3ZN-0004Pv-HL for ged-emacs-devel@m.gmane-mx.org; Tue, 24 Dec 2024 12:59:25 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tQ3Yw-0002TY-GV; Tue, 24 Dec 2024 06:58:58 -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 1tQ26l-0000OI-IV for emacs-devel@gnu.org; Tue, 24 Dec 2024 05:25:48 -0500 Original-Received: from mail-10628.protonmail.ch ([79.135.106.28]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tQ26j-0006v5-La; Tue, 24 Dec 2024 05:25:47 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1735035942; x=1735295142; bh=tVbcbk0cc4doGLPCsLSNzjUUWc6s0JjOADedjRN2w8A=; 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=vFx8WKHXwuYKHuALhKjrmbknyKTfdvk4lNFbeVWnWeDjuBXuw69oMmAB2TNSZrvvM Ksb8BMY98wlaDuoex91dqd2OHpwEAz3/W23pyqZapG/PMu6BlftIfCaSCNizICn/PV TL0nLZL1HzE4fnOBKI5CbF6JR5q9NL1x7Mjz/BLkJr7RdH0vxEWbLu8P7gu+rHCw/4 BiRiV0fW4LVY9oLvIISR87ZpHiLQXxUY9Ey4jJlhsS/zjuHrBt4RVob5r7+tuWUR78 YobUWolz5UI5zLtMCTG6Bx9FC8UvisNyVtx/e++n8E1t7JWtc1Zh2E5sonZV0812aA eHy4kJeQncqwA== In-Reply-To: Feedback-ID: 112775352:user:proton X-Pm-Message-ID: be407f157f1623478f9d2a7c4871dd9a90d28322 Received-SPF: pass client-ip=79.135.106.28; envelope-from=pipcet@protonmail.com; helo=mail-10628.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=ham autolearn_force=no X-Spam_action: no action X-Mailman-Approved-At: Tue, 24 Dec 2024 06:58:54 -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:326990 Archived-At: Gerd M=C3=B6llmann writes: > New day, new beliefs :-). Today, when I read my question again, I'd > actually be surprised if a signal handler could allocate Lisp objects > because I wouldn't be able to explain how that works with alloc.c which > isn't reentrant. Not even Fcons is reentrant when I look at it now. > > Correct, or am I overlooking something? Could others please check? If > it's right, things get a lot easier. I agree. But Eli said something about wanting to run Lisp from a signal handler, which would change that. I was trying to explain why we don't want to do that. > Maybe allocation of Lisp objects on the stack remains as some sort of > problem (AUTO_CONS etc)? I don't see how though, ATM. Stack objects are always optional, so if there is code that attempts to avoid alloc.c by using those, it's broken. My current patch makes it so the main thread never takes the arena lock, ever. Performance isn't quite the same as scratch/igc: for some reason I don't understand, it's slightly better. Still needs cleanup, de-pthreading, and we probably don't need to use atomic types everywhere. Pip