Re: Debugging Emacs with threads

[Ken Raeburn <raeburn@raeburn.org>]

On Dec 11, 2016, at 11:43, Andreas Schwab <schwab@linux-m68k.org> wrote:

> On Dez 11 2016, Eli Zaretskii <eliz@gnu.org> 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