Re: list-threads

[Gemini Lasswell]

Eli Zaretskii <address@hidden> writes:

> If a thread is running, no other thread will be able to run, so you
> will be unable to take the backtrace of that running thread.  Right?

I don't understand the question, but I can try to explain what I'm
thinking in more detail.

In the command which I haven't written yet called
thread-list-pop-to-backtrace, I'll get the thread at point and compare
it to the current thread. If they are the same then I can make a
backtrace buffer in the usual way, by using mapbacktrace to collect all
the frames (or call the new backtrace-get-frames which does that), and
the backtrace will include command-execute through
thread-list-pop-to-backtrace, and it will not be very interesting unless
there's a recursive edit or something going on.

If the thread at point is not the current thread, then I'll call the new
primitive that I'm working on, maybe to be called
backtrace--get-frames-from-thread, pass it the thread as an argument,
and it will cons up a list of backtrace frames using that thread's
specpdl stack, which I can use to fill my backtrace buffer.

As an experiment I added a thread argument to mapbacktrace, and changed
it and its subroutines to use thread->m_specpdl instead of specpdl, etc.
That works and lets me get backtraces from threads other than the
current one whether blocked or just yielded, but the problem with
mapbacktrace is that it calls a Lisp function which could yield and
allow the thread to run that I'm trying to get the backtrace of.  Hence
the new primitive.

I'd also like to collect local variable names and values for the
backtrace frames of the other thread, but I don't know how easy that
will be because I don't yet understand the backtrace_eval_unrewind hack
in backtrace--locals well enough to know if I can make it work safely on
threads other than the current one.