Re: [Emacs-diffs] trunk r113437: New unwind-protect flavors to better type-check C callbacks.

[Stefan Monnier]

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

Why?

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

Oh, man, that's even worse than I thought.  This is really bad, it means
that it suffers from the same kind of limitations as alloca, i.e. it is
tricky to use and coders need to be extra aware of it (e.g. common code
refactoring can be unsafe).

> 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

We've lived with it for what... almost 30 years?

> This would slow down execution very slightly, though.

As mentioned, the extra cases in unbind_to also cause a minor slowdown,
so I don't think this is a significant argument.

>> 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 problem is not the number of instructions but the time taken by each
instruction because correctly predicting indirect jumps is very
expensive and adding cases to the switch will increase the number
of mispredictions.


        Stefan