Re: MPS: scroll-bars

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

Eli Zaretskii <eliz@gnu.org> writes:

> My conclusions:
>
>   . scroll-bar Lisp object is a pseudovector
>   . w->vertical_scroll_bar is set to the window's scroll-bar object
>   . scroll-bar objects of a frame are stored in a doubly-linked list
>     via the ->prev and ->next C pointers of 'struct scroll_bar'
>   . frame's f->scroll_bars points to the last scroll-bar object
>     created for the frame's windows, and thus effectively to the
>     linked list of the frame's scroll bars
>   . similarly, a frame has f->condemned_scroll_bars, which is a
>     doubly-linked list of condemned scroll bars, the ones that could
>     be deleted as result of redisplay (e.g., because their window were
>     deleted)

  /* 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;

Oh shit :-(. I need a break.

> Moreover (and this is w32-specific, I think), the Lisp thread sends a
> GUI message to the UI thread with the pointer to 'struct scroll_bar',
> via the call to my_create_hscrollbar:
>
>     case WM_EMACS_CREATEVSCROLLBAR:
>       return (LRESULT) w32_createvscrollbar ((struct frame *) wParam,
> 					     (struct scroll_bar *) lParam);
>
>   static HWND
>   my_create_vscrollbar (struct frame * f, struct scroll_bar * bar)
>   {
>     return (HWND) SendMessage (FRAME_W32_WINDOW (f),
> 			       WM_EMACS_CREATEVSCROLLBAR, (WPARAM) f,
> 			       (LPARAM) bar); <<<<<<<<<<<<<<<<<<<<<<<<
>   }
>
> the UI thread then uses the members of 'bar' like this:
>
>   static HWND
>   w32_createvscrollbar (struct frame *f, struct scroll_bar * bar)
>   {
>     HWND hwnd = CreateWindow ("SCROLLBAR", "",
> 			 /* Clip siblings so we don't draw over child
> 			    frames.  Apparently this is not always
> 			    sufficient so we also try to make bar windows
> 			    bottommost.  */
> 			 SBS_VERT | WS_CHILD | WS_VISIBLE | WS_CLIPSIBLINGS,
> 			 /* Position and size of scroll bar.  */
> 			 bar->left, bar->top, bar->width, bar->height,
> 			 FRAME_W32_WINDOW (f), NULL, hinst, NULL);
>
> 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.

> 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.

Then I think we first of all must make sure that MPS knows about that
thread. 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.