On 06/03/12 17:05, Sean Kelly wrote:
On Mar 6, 2012, at 3:14 AM, Don Clugston<d...@nospam.com> wrote:
Responding to traps is one of the very few examples I know of, where Windows
got it completely right,
and *nix got it absolutely completely wrong. Most notably, the hardware is
*designed* for floating point traps to be fully recoverable. It makes perfect
sense to catch them and continue.
But unfortunately the *nix operating systems are completely broken in this
regard and there's nothing we can do to fix them.
Does SEH allow recovery at the point of error like signals do?
Yes, it does. It really acts like an interrupt. You can, for example,
modify registers or memory locations, then perform the equivalent of an
asm { iret; }, so that you continue at the next instruction. Or, you can
pass control to any function, after unwinding the stack by any number of
frames you chose. And, you regain control if any other exception occurs
during the unwinding, and you're given the chance to change strategy at
that point.
An SEH handler behaves a bit like setjmp(), it's not a callback.
Most importantly, in comparison to Posix, there are NO LIMITATIONS about
what you can do in an SEH exception handler. You can call any function
you like.
The documentation is terrible, but it's really a beautiful design.
Sometimes I think it would be enough if the Posix spec were worded in
a way that allowed exceptions to be thrown from signal handlers.
I think that would be difficult to allow. Some of the restrictions seem
to be quite fundamental. (Otherwise, I'm sure they would have got rid of
them by now!)
