Re: MPS: w32 threads

[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 12:04:50 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > How to go about that?
> 
> Please let's first do the thread stuff. That makes things easier for the
> old man here.

OK.  I've started a new thread (pun intended) for this branch of the
discussion.

> >> 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.
> 
> Does it have a struct thread_state associated with it? That's what
> igc.c currently knows how to handle.

No.  Only Lisp threads started with make-thread have thread_state.

> A thread must be registered with an arena if:
> 
> its control stack and registers form a root (this is enforced by
> mps_root_create_thread()); or it reads or writes from a location in an
> automatically managed pool in the arena. However, some automatically
> managed pool classes may be more liberal than this. See the
> documentation for the pool class.

Can you try translating this to Emacs-related terms, please?  What
activities in the thread should require the thread to be "registered
with an arena"?

Emacs on Windows starts separate threads for the following jobs:

  . processing Windows GUI-related messages
  . reading from sub-processes (part of pselect emulation)
  . emulation of itimers (for atimers and for M-x profiler)
  . file-change notifications

I need to understand what traits of a thread make it need to be
registered with MPS.  Each of the above will then need a separate
audit, I think.