From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Gemini Lasswell Newsgroups: gmane.emacs.devel Subject: Re: list-threads Date: Wed, 01 Aug 2018 13:04:18 -0700 Message-ID: <87wot9onul.fsf@runbox.com> References: <87tvoiq208.fsf@runbox.com> <83pnz4py5t.fsf@gnu.org> <874lgeoz0h.fsf@runbox.com> <83o9emm4ab.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1533153767 21376 195.159.176.226 (1 Aug 2018 20:02:47 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 1 Aug 2018 20:02:47 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1.50 (gnu/linux) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Aug 01 22:02:43 2018 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fkxKV-0005T9-HE for ged-emacs-devel@m.gmane.org; Wed, 01 Aug 2018 22:02:43 +0200 Original-Received: from localhost ([::1]:42707 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fkxMc-0005Fr-73 for ged-emacs-devel@m.gmane.org; Wed, 01 Aug 2018 16:04:54 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:42287) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fkxMP-0005Av-QX for emacs-devel@gnu.org; Wed, 01 Aug 2018 16:04:42 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fkxML-0002XZ-Bt for emacs-devel@gnu.org; Wed, 01 Aug 2018 16:04:41 -0400 Original-Received: from aibo.runbox.com ([91.220.196.211]:37844) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1fkxML-0002X1-01; Wed, 01 Aug 2018 16:04:37 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=runbox.com; s=rbselector1; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From; bh=CVWAJ++YyFrAEXkPrGUoc9gwhlm80x3lc294AtZ3RI0=; b=JMYkJN5/NB8SORoq689Y65OTvd JR0SlANeo1IpYCB39qpvfGqI5zbLLfd4mQDLQVSi9X6NmkgmXXMk/if582Mw72WApS9CvtaJMO4fA 4fUSB7QQ2dwIUxjfWSpN4amfQVDs6J1KowC1nESY5h5BmMC1e9MV+YrJJednO+PaIQ0iWEj2S7l6b 4QPAldqqjH/P0IBXZZj0vPjAKxhl1ZlLXtrftocX0EyYb9iTGsCjRt/3IHiiEURpDg8DfxeoZR18b d11vZNZdVcZu2PGGJPETotZwSNr9t9TPTatT0F0d9bnY378txlCTnlda2dHDKfybaaSxCCif2fi6l rnHQBaSA==; Original-Received: from [10.9.9.210] (helo=mailfront10.runbox.com) by mailtransmit02.runbox with esmtp (Exim 4.86_2) (envelope-from ) id 1fkxMJ-0002na-IY; Wed, 01 Aug 2018 22:04:35 +0200 Original-Received: by mailfront10.runbox.com with esmtpsa (uid:179284 ) (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) id 1fkxM4-0000Pu-Ad; Wed, 01 Aug 2018 22:04:20 +0200 In-Reply-To: <83o9emm4ab.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 01 Aug 2018 19:37:32 +0300") X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 91.220.196.211 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:228093 Archived-At: Eli Zaretskii 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.