Re: MPS: scroll-bars

[Eli Zaretskii <eliz@gnu.org>]

> From: Helmut Eller <eller.helmut@gmail.com>
> Cc: Gerd Möllmann <gerd.moellmann@gmail.com>,
>   emacs-devel@gnu.org
> Date: Tue, 07 May 2024 08:07:04 +0200
> 
> On Mon, May 06 2024, Eli Zaretskii wrote:
> 
> >> > Btw, did we decide what to do with these chains:
> >> >
> >> >   struct frame
> >> >   {
> >> >   [...]
> >> >   /* List of scroll bars on this frame.
> >> >      Actually, we don't specify exactly what is stored here at all; the
> >> >      scroll bar implementation code can use it to store anything it likes.
> >> >      This field is marked by the garbage collector.  It is here
> >> >      instead of in the `device' structure so that the garbage
> >> >      collector doesn't need to look inside the window-system-dependent
> >> >      structure.  */
> >> >   Lisp_Object scroll_bars;
> >> >   Lisp_Object condemned_scroll_bars;
> >> >
> >> > They are doubly-linked lists via the ->next and ->prev fields in the C
> >> > 'struct scroll_bar', in X as well as w32, see XSCROLL_BAR.  The
> >> > Lisp_Object's above are the last scroll bar on the frame's windows,
> >> > and the rest are reachable via the ->next and ->prev pointers.  Do we
> >> > need to do anything about those ->next and ->prev pointers?
> [...]
> > Helmut, WDYT about the scroll bars on X (and by extension on w32)?
> 
> On X, the struct scroll_bar is allocated as a PVEC_OTHER pseudovector.

Likewise on w32.

> And I think the next/prev links are traced because of that.
> xterm.c:mark_xterm doesn't do anything special for scrollbars, so I
> think it's all covered.

So any C pointers within a Lisp object allocated via MPS are
automatically traced and fixed when the object is moved?

> The only complication so far was that a struct
> scroll_bar* was handed to GTK that was not traced; after I turned that
> into a root with a pointer to the scroll_bar* it is traced.

Is this the only/best way of making a structure pinned?  If there are
others, what are they?  I wonder if there's a more elegant technique
than to use indirection.  E.g., can't I tell MPS somehow that a Lisp
object allocated as PVEC_OTHER pseudovector is pinned?

See, on w32 the pointer to 'struct scroll_bar' is handed to the UI
thread (via a message with parameters), which uses it to tell the
MS-Windows GUI system how to create the scroll bar (which is just a
special kind of window, as far as MS-Windows is concerned).  So I
think the 'struct scroll_bar' must not be allowed to be moved on w32,
because if it does, the UI thread will dereference invalid pointers.