> How exceptional exceptions really are depends on the code being run.

Well yes, but EH is basically trying to be the best way to do a highly non-local goto with a dynamic target. If that part is your bottleneck than indeed you may have a more specialized requirement.

I do on occasion build a homemade version of a standard library datatype because I have a specialized need and only need implement the subset our code will call. That doesn't invalidate the more general implementations in the standard library (which tend to be quite good, even corner cases).

Likewise sometimes I check for a null pointer being returned or other local error flag. That doesn't mean I don't think exceptions are a good idea.

> The serialization of stack unwinding issue is a real serious problem.

That is the important part of the paper and as I wrote in my comment, I am disappointed that a possible solution, written and tested by the paper's author, was dismissed.

I agree. I'm not sure breaking the ABI to fix the unwinder serialization issue should be a show-stopper, considering that there still isn't a C++ ABI.

Th problem is that the corpus of deployed libraries is a de facto ABI. Even with dylib versioning, catching the case of API version is hard.

I think it could be done by changing the mangling algorithm (basically: compile fails if new-ABI versions are not available) but I haven't thought enough about it to remove the words "I think" from the beginning of the sentence.

Since this is about immutable "side car" data structures used during unwinding: could this be achieved using a soft ABI transition as opposed to a hard, flag day ABI break?

Basically, going forward the compiler would emit two versions of the unwinding tables by default: the legacy one and the one that allows fixing the thread contention issue. The unwinder is changed to use the efficient version by default with the ability to fall back to locking if it encounters a shared object that only has the old version.

Space conscious users could choose to emit only one version by using a compiler flag, and after a decade or so the compiler is switched to only emit the new version by default (but the unwinder could retain the capability to understand the old format for a few decades longer).

It seems like most of the table contents should even be shareable between versions? The locking seems to be only there to guard against shared object loading/unloading which should only affect the topmost level of the data structure.

Admittedly I have no idea how those tables are actually defined today.

That might work. It would be yet another thing that would slow down compilation (link phase in this case) but not the worst.

Compilers would have to generate both forms forever (except for new architectures) but probably that wouldn’t be terrible.

It only took ~two decades to remove a.out support from the Linux kernel :)

(I wonder when software engineers will more commonly think about their work on a generational time scale. Like how the cathedral builders of old must have thought about their work...)

There are platform specific ABIs and there have been for many years. Many platforms want to preserve the ABI at all costs.

In any case this doesn't seem to be an ABI issue

I would think it shouldn't be an ABI issue, but maybe part of the unwinding code gets statically linked into shared objects?