unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Tom Tromey <tom@tromey.com>
To: emacs-devel@gnu.org
Subject: please review new branch feature/byte-unwind-protect
Date: Mon, 22 Jan 2018 22:20:36 -0700	[thread overview]
Message-ID: <87inbtnobf.fsf@tromey.com> (raw)

Hi.

I recently wrote a couple of patches to add two new bytecodes to Emacs.
These make it possible to compile unwind-protect without the need to
introduce a closure for the unwind forms.

I've pushed these to feature/byte-unwind-protect.  They seem to be
working pretty well, so I would appreciate a review.  I'd like to merge
these to trunk.

The first patch changes the C code so that a CATCHER_ALL handler sees
both signals and throws.  In addition to being needed for the second
patch, this allowed some simplifications in the module code.  Note that
this changes the interface exposed by internal_catch_all, but as there
is only one caller, it is easy to verify that the change doesn't matter.

The second patch adds the new bytecodes and updates the byte compiler.
Two bytecodes are added.

The first, Bpushunwindprotect, pushes a CATCHER_ALL handler.  On error,
it then pushes the exception value and `t' and jumps to the unwind
forms.  When there is no error, the body form's value is left on the
stack and then an additional `nil' is pushed.

The second bytecode, Bendunwindprotect, looks at the top of the stack
and decides whether to carry on or to call `signal' or `throw'.

It's possible that this new bytecode could be used to remove the
unwind-protect restrictions in generator.el, though I didn't look deeply
into that.

thanks,
Tom



             reply	other threads:[~2018-01-23  5:20 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-23  5:20 Tom Tromey [this message]
2018-01-23  8:47 ` please review new branch feature/byte-unwind-protect John Wiegley
2018-01-23 15:50   ` Tom Tromey
2018-01-23 16:37     ` Stefan Monnier
2018-01-27 17:37 ` Markus Triska
2018-01-27 21:28   ` Stefan Monnier
2018-02-03 19:43 ` Philipp Stephani
  -- strict thread matches above, loose matches on Subject: below --
2018-01-26  7:58 Rocky Bernstein

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87inbtnobf.fsf@tromey.com \
    --to=tom@tromey.com \
    --cc=emacs-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).