[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Emacs-diffs] trunk r113437: New unwind-protect flavors to better ty

From: Paul Eggert
Subject: Re: [Emacs-diffs] trunk r113437: New unwind-protect flavors to better type-check C callbacks.
Date: Tue, 23 Jul 2013 10:00:53 +0100
User-agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130623 Thunderbird/17.0.7

On 07/22/2013 05:13 AM, Stefan Monnier wrote:
> I much preferred having a single record_unwind.

The old way was simpler, but it had a problem:
record_unbind_protect (foo, make_save_value (...))  didn't
work when make_save_value exhausted memory and threw an
error.  To avoid the problem, there needs to be a way to
invoke record_unwind_protect without the possibility of
throwing an error before the protection is in place.

record_unwind_protect_ptr does that, since the caller
already can have a local variable in the C stack, and pass
its address.  This works because every function that calls
record_unwind_protect_ptr also calls unbind_to to undo it,
before returning.

It wouldn't be feasible to convert all uses of
record_unwind_protect to record_unwind_protect_ptr, because
not every function that calls record_unbind_protect also
calls unbind_to.

Removing record_unwind_protect_int would not be trivial,
since one can't simply replace it with record_unwind_protect
+ make_integer (as not all 'int' values fit into Lisp
integers), and one can't simply replace it by passing an int
* to record_unwind_protect_ptr (as not all functions that
invoke record_unwind_protect_int also call unbind_to).

We could trivially remove record_unwind_protect_void by
using one of the other methods and passing a dummy argument.
This would slow down execution very slightly, though.  Plus,
an advantage of having record_unwind_protect_void and
record_unwind_protect_int is it catches more type errors at
the C level.

> No strong technical arguments for it (other than the fact that the
> added SPECPDL_UNWIND_* cases in the switch slow down `unbind').

It shouldn't slow down 'unbind', at least on my x86-64
platform, since the switch is implemented as an indirect
jump, which means that adding cases doesn't add any
instructions for the existing cases.  The new code should
even speed up 'unbind' a tad, at least for the void case,
since it can avoid passing an argument that the unwinder
doesn't look at.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]