Re: MPS: scroll-bars

["Gerd Möllmann" <gerd.moellmann@gmail.com>]

Eli Zaretskii <eliz@gnu.org> writes:

>> Date: Sun, 05 May 2024 21:09:53 +0300
>> From: Eli Zaretskii <eliz@gnu.org>
>> Cc: gerd.moellmann@gmail.com, luangruo@yahoo.com, emacs-devel@gnu.org
>> 
>> > From: Helmut Eller <eller.helmut@gmail.com>
>> > Cc: gerd.moellmann@gmail.com,  luangruo@yahoo.com,  emacs-devel@gnu.org
>> > Date: Sun, 05 May 2024 20:02:13 +0200
>> > 
>> > On Sun, May 05 2024, Eli Zaretskii wrote:
>> > 
>> > > Can you tell, for my own education, what does a call to
>> > > igc_xzalloc_ambig give us, as opposed to just xzalloc?
>> > 
>> > igc_xzalloc_ambig allocates memory like xzalloc but it addition
>> > registers it as root.  When MPS starts scanning, it begins from the
>> > roots.  That means, we are sure that the referenced objects stay alive.
>> > In the case of ambiguous references, the objects are also pinned
>> > (i.e. don't move).
>> > 
>> > That pinning part is not necessary for the scroll-bar case, but
>> > igc_xzalloc_ambig is currently the easiest to use function available in
>> > igc.h.
>> 
>> Thanks, I think I get this.
>
> 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?

For NS, and I must always add that I don't know NS at all, the
condemned_scroll_bars are fine I think. NS sets a flag in an NS
EmacsScroller object to condemn/redeem it, and doesn't use the frame's
field, says clangd.

The scroll_bars field was something strange. It didn't contain struct
scroll_bars but someting like optimized Lisp_Misc_Ptrs (see
xmint_pointer in lisp.h) which point to EmacsScrollers.

In summary, I came for NS to the conclusion that we should be good with
what we currently have. Famous last words.