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 19:45:05 +0300 Message-ID: <864jbgkvse.fsf@gnu.org> References: <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> <86msp8lbci.fsf@gnu.org> <86ikzwl8ih.fsf@gnu.org> <86cyq4l02u.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="31056"; 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 18:46:52 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 1s2Za8-0007tc-Ji for ged-emacs-devel@m.gmane-mx.org; Thu, 02 May 2024 18:46:52 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1s2ZZM-0004UJ-ED; Thu, 02 May 2024 12:46:04 -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 1s2ZZJ-0004Tf-Vp for emacs-devel@gnu.org; Thu, 02 May 2024 12:46: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 1s2ZZI-0004VA-8r; Thu, 02 May 2024 12:46:01 -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=tvK60n1LmYM+Y5ve95tUjPrqIMqOrB7qgNSfqGpUO6s=; b=qXmG4be9EFsApo3ygdAi 8vMvEqDAkiSnXSLHeRuKa+SdDzbxEV9nASC4Y//04kG0xWwkv3JgGgd7rtzdAkL9H3Upx9ZG+I1Fs H05GSntH+xUGBU1rFT8tYRtkiyD+NzUhZu/TDT5grCwDkpdF221DT1QYANhpzuI1XvESgz9uB2BR3 jmzxBhzekQisv0dZ1oUHISEHLFhMFzJWD+QGhgJUf/UMBPEgZ9u/Ifq8GYOl0GkC8gAJRGahws0W2 0BYuJdqNyeqq1c/rtLsWRnrrb0wYvrIHsOtsT8yCjsNt8JoOW4R1xx0KZa1IEasS0M5jLa3vTP04p hdsiIMzNVRTWAA==; In-Reply-To: (message from Gerd =?utf-8?Q?M=C3=B6llmann?= on Thu, 02 May 2024 17:55: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:318596 Archived-At: > From: Gerd Möllmann > Cc: eller.helmut@gmail.com, emacs-devel@gnu.org > Date: Thu, 02 May 2024 17:55:43 +0200 > > Eli Zaretskii writes: > > >> I now wonder: If struct it always lives on the stack (I think that's still > >> true?), then it->w is also on the stack, and thus it->w is immovable by > >> fact fact. Right? > > > > Yes. So you are saying there's no problem, neither with it->w, nor > > with it->bidi_it.w, and thus the cached bidi_it objects are also safe > > in this aspect? > > I think so, but I have limited understanding of what's going on. If > there is always some struct it on the stack that has the same it->w as > what struct bidi_it then I think we are safe. That's what happens. A typical redisplay cycle looks like this: int try_window (Lisp_Object window, struct text_pos pos, int flags) { struct window *w = XWINDOW (window); struct it it; [...] start_display (&it, w, pos); [...] /* Display all lines of W. */ while (it.current_y < it.last_visible_y) { [...] if (display_line (&it, cursor_vpos)) last_text_row = it.glyph_row - 1; [...] } And all the "action", including calls to bidi.c, happens inside display_line. The call to start_display above initializes its IT argument by setting it->w to the 2nd argument W. It also initializes it->bidi_it, and sets it->bidi_it.w to the same argument W. IOW, the top-level caller of any display iteration uses a stack-based variable of the type 'struct it', of which 'struct bidi_it' is a field. So, to summarize: we have concluded that the 'struct window' to which it->w and it->bidi_it.w point will not be moved in memory as long as struct it is on the C stack, and therefore the bidi_it.w pointers stored in bidi_cache will be valid. Is that right?