[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: MPS: w32 threads
From: |
Eli Zaretskii |
Subject: |
Re: MPS: w32 threads |
Date: |
Sat, 04 May 2024 16:59:47 +0300 |
> 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.
- Re: MPS: scroll-bars, (continued)
- Re: MPS: scroll-bars, Helmut Eller, 2024/05/04
- Re: MPS: scroll-bars, Gerd Möllmann, 2024/05/04
- Re: MPS: scroll-bars, Helmut Eller, 2024/05/04
- Re: MPS: scroll-bars, Gerd Möllmann, 2024/05/04
- Re: MPS: scroll-bars, Gerd Möllmann, 2024/05/04
- Re: MPS: scroll-bars, Gerd Möllmann, 2024/05/04
- Re: MPS: scroll-bars, Eli Zaretskii, 2024/05/04
- Re: MPS: scroll-bars, Gerd Möllmann, 2024/05/04
- Re: MPS: scroll-bars, Eli Zaretskii, 2024/05/04
- Re: MPS: scroll-bars, Gerd Möllmann, 2024/05/04
- Re: MPS: w32 threads,
Eli Zaretskii <=
- Re: MPS: w32 threads, Gerd Möllmann, 2024/05/04
- Re: MPS: w32 threads, Eli Zaretskii, 2024/05/05
- Re: MPS: w32 threads, Gerd Möllmann, 2024/05/05
- Re: MPS: w32 threads, Eli Zaretskii, 2024/05/05
- Re: MPS: w32 threads, Gerd Möllmann, 2024/05/05
- Re: MPS: w32 threads, Gerd Möllmann, 2024/05/05
- Re: MPS: scroll-bars, Po Lu, 2024/05/04
- Re: MPS: scroll-bars, Gerd Möllmann, 2024/05/05
- Re: MPS: scroll-bars, Helmut Eller, 2024/05/05
- Re: MPS: scroll-bars, Gerd Möllmann, 2024/05/05