MPS: which threads need to be registered and how?

MPS: which threads need to be registered and how?

[Eli Zaretskii]

The MPS documentation talks about registering threads with MPS.
However, AFAIU this is only needed if a thread either allocates memory
from MPS or accesses memory that is managed by MPS.  Is that correct?

Further, AFAIU memory allocation from MPS is done by calling 'alloc'
in igc.c.  The other memory-allocation functions (xmalloc, xzalloc,
xpalloc, malloc, and all their callers allocate memory from the heap
managed by libc, and MPS does not manage that memory and doesn't need
to know about it.  Is that correct?

The reason I'm asking is that the MS-Windows build of Emacs starts 4
application threads for various purposes.  These are:

  . The I/O thread which handles communications with Windows GUI
    subsystem by exchanging messages with it.  This thread accesses
    some structures of the Lisp machine, most notably the frames'
    list, the frame/window objects, and also some of the variables
    defied via DEFVAR_LISP.  I understand that this thread needs to be
    registered with MPS, is that right?

  . The reader threads started for each sub-process and each network
    or serial connection.  These threads do not allocate any memory,
    and correspond with the main thread via 2 static data structures
    and by using OS synchronization means like critical sections and
    events.  I understand that this thread does NOT need to be
    registered with MPS, is that true?

  . Timer threads used to implement interval timers and profiling.
    There can be at most 2 such threads, and they also communicate
    with the main thread via static structures.  But here there's a
    twist: when the timer expires, the timer thread stops the main
    thread, and then calls the signal handler directly.  SIGALRM
    handler just sets a flag, but SIGPROF handler can call
    record_backtrace, which accesses specpdl.  Does the profiling
    thread need to be registered with MPS?

  . The file-notifications threads.  These allocate memory by calling
    malloc, xmalloc, etc., but doesn't access any MPS-manged memory or
    the Lisp data.  I understand that this thread does NOT need to be
    registered with MPS, is that true?

My other questions are how and when to register a thread and how/when
to deregister it.  I understand that registration is done by calling
mps_thread_reg, but is it okay to call this from the thread function
as its first thing?  And is it okay to deregister a thread just before
it exits, i.e. when the thread function still runs?

Re: MPS: which threads need to be registered and how?

[Gerd Möllmann]

Eli Zaretskii <eliz@gnu.org> writes:

> The MPS documentation talks about registering threads with MPS.
> However, AFAIU this is only needed if a thread either allocates memory
> from MPS or accesses memory that is managed by MPS.  Is that correct?

I think it is. As soon as a thread's stack or registers can contain
references, it should be registered.

>
> Further, AFAIU memory allocation from MPS is done by calling 'alloc'
> in igc.c.  The other memory-allocation functions (xmalloc, xzalloc,
> xpalloc, malloc, and all their callers allocate memory from the heap
> managed by libc, and MPS does not manage that memory and doesn't need
> to know about it.  Is that correct?

Yes, alloc_impl is currently the only function allocating from MPS.
Everything else is implemented in terms of alloc_impl.

MPS doesn't need to know about nay other memory allocations, with one
exception. If that memory contains references, we need to make it a
root. That's the reason for the igc_xzalloc and so on functions.

> The reason I'm asking is that the MS-Windows build of Emacs starts 4
> application threads for various purposes.  These are:
>
>   . The I/O thread which handles communications with Windows GUI
>     subsystem by exchanging messages with it.  This thread accesses
>     some structures of the Lisp machine, most notably the frames'
>     list, the frame/window objects, and also some of the variables
>     defied via DEFVAR_LISP.  I understand that this thread needs to be
>     registered with MPS, is that right?

Yes, for sure.

>   . The reader threads started for each sub-process and each network
>     or serial connection.  These threads do not allocate any memory,
>     and correspond with the main thread via 2 static data structures
>     and by using OS synchronization means like critical sections and
>     events.  I understand that this thread does NOT need to be
>     registered with MPS, is that true?

Hard to tell for me. If they don't use Lisp_Objects or pointers to
memory allocated from MPS, then not. 

>   . Timer threads used to implement interval timers and profiling.
>     There can be at most 2 such threads, and they also communicate
>     with the main thread via static structures.  But here there's a
>     twist: when the timer expires, the timer thread stops the main
>     thread, and then calls the signal handler directly.  SIGALRM
>     handler just sets a flag, but SIGPROF handler can call
>     record_backtrace, which accesses specpdl.  Does the profiling
>     thread need to be registered with MPS?

The sounds like it need registration because it seems unavoidable to me
that the thread's stack or registers can contain references. I'd also
give it allocation points because record_backtrace sounds like it might
cons.

>   . The file-notifications threads.  These allocate memory by calling
>     malloc, xmalloc, etc., but doesn't access any MPS-manged memory or
>     the Lisp data.  I understand that this thread does NOT need to be
>     registered with MPS, is that true?

Sounds like it doesn't need registration, that's right.

> My other questions are how and when to register a thread and how/when
> to deregister it.  I understand that registration is done by calling
> mps_thread_reg, but is it okay to call this from the thread function
> as its first thing?  And is it okay to deregister a thread just before
> it exits, i.e. when the thread function still runs?

That's how I did it in thread.c. One of the first things in run_thread, 
is register the thread, and one of the last things is ti deregister it.