Re: MPS: scroll-bars

[Eli Zaretskii <eliz@gnu.org>]

> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> Cc: eller.helmut@gmail.com,  luangruo@yahoo.com,  emacs-devel@gnu.org
> Date: Sat, 04 May 2024 11:13:40 +0200
> 
> > So, what does this mean in the MPS build?  I guess we need to make
> > sure scroll bars don't move, for the reference across threads to work?
> 
> That would be my guess as well.

How to go about that?

> > I see that allocate_pseudovector does:
> >
> >   struct Lisp_Vector *
> >   igc_alloc_pseudovector (size_t nwords_mem, size_t nwords_lisp,
> > 			  size_t nwords_zero, enum pvec_type tag)
> >   {
> >     struct Lisp_Vector *v
> >       = alloc (header_size + nwords_mem * word_size, IGC_OBJ_VECTOR, tag);
> >     XSETPVECTYPESIZE (v, tag, nwords_lisp, nwords_mem - nwords_lisp);
> >     maybe_finalize (v, tag);
> >     return v;
> >   }
> >
> > But still for the life of me I don't really understand what that means
> > for us in this case.  What does it mean for the references to its C
> > 'struct scroll_bar' when the scroll-bar object is moved?  If any of
> > these references are on some thread's stack, does it mean the object
> > will not move?  And what about those prev and next pointers in frame's
> > scroll_bars lists -- do we need to do anything with them?  Likewise
> > with the window's vertical_scroll_bar pointers.
> 
> I assume that the GUI thread you mention is not one the Emacs threads,
> but something else, so it's not main_thread and not one of the threads
> made with make-thread.

It isn't a Lisp thread, that's true.  But it's an "Emacs thread" in
the sense that in the w32 build it is an integral part of Emacs, and
without it the GUI features and GUI I/O would not work on MS-Windows.

(You can find the overview of the thread structure of the w32 build in
a large comment that starts at line 3365 of w32fns.c.)

> Then I think we first of all must make sure that MPS knows about that
> thread.

Why do we need MPS to know about that thread (or any other non-Lisp
thread used by Emacs on MS-Windows; there are more)?  is that for MPS
to scan their C stacks and registers?

> The existing threads are added with thread_add
> 
>   static struct igc_thread_list *
>   thread_add (struct thread_state *ts)
>   {
>     mps_thr_t thr;
>     mps_res_t res = mps_thread_reg (&thr, global_igc->arena);
>     IGC_CHECK_RES (res);
>     struct igc_thread_list *t = register_thread (global_igc, thr, ts);
> 
>   That's the root for the control stack of the thread:
> 
>     root_create_thread (t);
> 
>   These are allocation points in case the thread allocates from MPS:
> 
>     create_thread_aps (&t->d);
>     return t;
>   }
> 
> Maybe we should start with this, and move forward when we have it.

I'd first like to understand the need and the purpose of registering
non-Lisp threads with MPS.