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: staticpro everything Date: Thu, 02 May 2024 14:09:01 +0300 Message-ID: <86msp8lbci.fsf@gnu.org> References: <87ttjlabic.fsf@gmail.com> <87v8408wsr.fsf@gmail.com> <87o79sasl5.fsf@gmail.com> <87plu72y8h.fsf@gmail.com> <877cgfwe5g.fsf_-_@gmail.com> <871q6mptkj.fsf@gmail.com> <86frv2pse5.fsf@gnu.org> <87v83ynhuc.fsf@gmail.com> <86v83xof5w.fsf@gnu.org> <878r0thbfl.fsf@gmail.com> <86jzkdo9rm.fsf@gnu.org> <87jzkdfres.fsf@gmail.com> <86plu4mylj.fsf@gnu.org> 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="21446"; mail-complaints-to="usenet@ciao.gmane.io" Cc: eller.helmut@gmail.com, emacs-devel@gnu.org To: Gerd =?utf-8?Q?M=C3=B6llmann?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu May 02 13:09:58 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 1s2UK6-0005KI-KA for ged-emacs-devel@m.gmane-mx.org; Thu, 02 May 2024 13:09:58 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1s2UJJ-0000R2-Db; Thu, 02 May 2024 07:09:09 -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 1s2UJG-0000PR-EW for emacs-devel@gnu.org; Thu, 02 May 2024 07:09:06 -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 1s2UJG-0005HH-5a; Thu, 02 May 2024 07:09:06 -0400 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=+4H5mq5/YNX4Z/BbapaOAcAs9Q3q5SyfPej/xn2OH9w=; b=kOwC7bRTXqS/cU0BIGu8 VJUdGnmJa3f+bLydlxovYuoq8BoP56J4qtjrOy2q44YMSfO+JgfWshKc2rppk9k4X0Ar607LYOwD7 6lL7QBeqZrVCpN8bz1Vobc6MiY24yxZFzdNaydMXfFHDOJ29XxB5WPOIbaFT/CXfV3MzAw5wHtN2X /wT/F2nE0JeG6b97cDnPo/ylPaDEvOVyrBtYm9y7fW/HhryIMXyZa2JCcQ8/d6UE7y8sYXNiRhvkU NhgriPBzHcOVjRDvxyEEQVhS5vCTJllYH9vr8iU0mTu35BB7IL9wR54JGKBsCEDPcsPyW0IZ/qLGz KGqnvYRhMYC1Mw==; In-Reply-To: (message from Gerd =?utf-8?Q?M=C3=B6llmann?= on Thu, 02 May 2024 11:04:43 +0200) 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:318565 Archived-At: > From: Gerd Möllmann > Cc: Helmut Eller , emacs-devel@gnu.org > Date: Thu, 02 May 2024 11:04:43 +0200 > > > Given this, what would be the best way of making sure the 'struct > > window' pointer in each bidi_it remains valid? The simplest idea that > > comes to my mind is to arrange for the window on which redisplay works > > to be unmovable. Would that solve the problem? If so, we could do > > that in init_iterator, which starts the display iteration process, and > > I can suggest a patch if you tell me how to do that with MPS. (I > > actually think that making the window being redisplayed unmovable is a > > Good Thing for other reasons, since it frees us from worrying about > > passing the 'struct window' pointer around, which we do liberally.) > > I would propose to use igc_xzalloc_ambig + igc_free in the MPS case > instead of xmalloc/xfree. There are also realloc, and palloc variants, > if you use that. > > This is the same as the normal malloc/free, but it also adds an ambig > root, so that anything references from the malloc'd memory becomes > immovable / doesn't die. It's the same as if that memory would be part > of the control stack. But doesn't that mean MPS will need to trace too much? Also, does the above mean my idea of making the window unmovable is not good? If so, can you explain why not?