[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Debugging Emacs with threads
From: |
Ken Raeburn |
Subject: |
Re: Debugging Emacs with threads |
Date: |
Sun, 11 Dec 2016 22:07:11 -0500 |
On Dec 11, 2016, at 11:43, Andreas Schwab <address@hidden> wrote:
> On Dez 11 2016, Eli Zaretskii <address@hidden> wrote:
>
>> When Emacs stops due to a breakpoint, the thread that is the current
>> one is in sync between GDB and Emacs. IOW, the current_thread
>> variable describes the same thread on which GDB commands will act.
>> But as soon as you say something like "thread 1" at the GDB prompt,
>> this synchronization is lost: GDB acts on the thread you specified,
>> while current_thread is still pointing at the thread which was the
>> current one when Emacs stopped.
>
> Why isn't current_thread a thread-local variable?
Multiple C threads can be running at once, but our current model for Lisp is
that only one thread runs at a time; current_thread is the indicator of which
thread that is, and that’s global to the process.
When we actually decide to start running a different Lisp thread from the
“current” one, we need to save the current dynamic state (let bindings, etc)
and restore that of the alternate thread. The thread wanting to “enter” the
Lisp environment acquires the global lock, saves the old thread’s state,
updates current_thread, restores its own state, and does its business.
This way, threads can release and re-acquire the global lock without having to
save and restore all their dynamic state each time, which is a win if we
release the lock more often than we actually switch between Lisp threads.
Ken