[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.