From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: [Emacs-diffs] feature/byte-unwind-protect 916094a 2/2: Add new bytecodes for unwind-protect Date: Tue, 23 Jan 2018 11:15:06 -0500 Message-ID: References: <20180123051231.6240.43062@vcs0.savannah.gnu.org> <20180123051232.EBBB6207FC@vcs0.savannah.gnu.org> <874lnck2a8.fsf@tromey.com> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1516724049 16813 195.159.176.226 (23 Jan 2018 16:14:09 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 23 Jan 2018 16:14:09 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Jan 23 17:14:05 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 1ee1Cf-0002lD-Jm for ged-emacs-devel@m.gmane.org; Tue, 23 Jan 2018 17:13:41 +0100 Original-Received: from localhost ([::1]:37966 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ee1Ef-0001D8-Tl for ged-emacs-devel@m.gmane.org; Tue, 23 Jan 2018 11:15:45 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:45550) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ee1EX-0001CY-Mc for emacs-devel@gnu.org; Tue, 23 Jan 2018 11:15:38 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ee1EU-00082X-6H for emacs-devel@gnu.org; Tue, 23 Jan 2018 11:15:37 -0500 Original-Received: from [195.159.176.226] (port=50081 helo=blaine.gmane.org) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1ee1ET-0007wC-RJ for emacs-devel@gnu.org; Tue, 23 Jan 2018 11:15:34 -0500 Original-Received: from list by blaine.gmane.org with local (Exim 4.84_2) (envelope-from ) id 1ee1CO-0001p4-Tp for emacs-devel@gnu.org; Tue, 23 Jan 2018 17:13:24 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 51 Original-X-Complaints-To: usenet@blaine.gmane.org Cancel-Lock: sha1:YHHsD+UCfxmVBbXzSseu6HHvNqo= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 195.159.176.226 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:222171 Archived-At: >>> + CASE (Bpushunwindprotect): /* New in 27.1. */ >>> + { >>> + struct handler *c = push_handler (Qt, CATCHER_ALL); > Stefan> Hmm... using this "catch+rethrow" method interferes with the > Stefan> debug-on-error stacktrace: > Hmm, yeah. > Any ideas for fixing this? Probably change the maybe_call_debugger code so it ignores CATCHER_ALL somehow. > One idea would be to capture the stack trace when CATCHER_ALL is > targeted, then have a way to pass this to signal or throw. In general, it'd be nice, yes, except that: > But often the stack trace isn't needed. Exactly. > Stefan> I also wonder if there can be places where we call something like > Stefan> `unbind_to` which should run those new unwind-forms but won't find it > Stefan> because it won't look at the handlers [ offhand, I can't think of any > Stefan> place where that would happen, and I think it's probably OK, but > Stefan> I can't quite convince myself that it definitely is. ] > If this happens then surely it's already a problem for catch and > condition-case? But having looked a bit more carefully at the code, I think we're OK, indeed. > Stefan> All in all, I'd really prefer if we kept the unwind forms in > Stefan> the specpdl. Was there a particular reason why you used the > Stefan> handlers instead? > This is how catch and condition-case are implemented. I know. But until now all the unwind forms are pushed to the specpdl, whereas the catcher and condition-case handlers go to the handlers stack. Your patch changes that by moving the unwind forms to the handlers stack (tho it keeps the "built-in unwinds" on the specpdl). > I do agree there's no reason to have a separate handler list. In fact > this puzzled me for a while. However I think it's a separate cleanup. Yes, merging the two is a different issue (last I looked at that code I was also tempted to go that way, but the two are used quite differently, so it's not clear there'd be much benefit). Stefan