Re: MPS: w32 threads

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

Eli Zaretskii <eliz@gnu.org> writes:

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

OK.

(Plus main_thread, which is a thread_state in the data segment (!) for
the main thread. Just in case someone wonders why main_thread is a
root.)

>> 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"?

It basically says that if a thread can have Lisp_Objects or pointers to
them on its control stack, register it with MPS.

An arena is basically an implementation of some low-level aspects of
memory managemnt in MPS. We have only one MPS arena, and it is one using
VM functions (mmap, ...).

The hint that some pool classes don't require this or that we can
ignore. AKAIK the mostly-copying pools we use require it.

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

Using any Lisp_Objects (or other objects allocated from MPS) -> register
it. AFAIU, the GUI thread gets such an objects posted in a message, so
that one must be registered.

The others are hard to say for me. It would not do harm to register
them, but might mean addtional work for nothing.