So even for official reviewed version I vote **Yes** under _condition_ that ABI issue is going to be fixed in whatever way the author seems to be correct.
Hi,
If I understand you don't need to choose between a fast (signal unaware) and a low (signal aware) implementation, but juts don't have ABI issues, isn't it?
Yes, current solution given in review is very dangerous from ABI point of view.
On top of the current implementation Oliver could implement a movable context that hides its implementation, but that will need an allocation.
My personal opinion is that pimpl based implementation would be better for a simple reason: 1. It would allow much better flexibility switching implementations without breaking ABI/API, consider a patch were some register was forgotten. and it requires room for this. 2. I think that "additional allocation" is premature optimization. As you are not expected to create contexts frequently and with context comes stack that would be much heavier operation to allocate then few hundred bytes for registers context. So trying to save this allocation is not correct way to do things. But both solutions are fine for me as long as there are not ABI issues. Artyom