Re: [boost] structured exceptions for UNIXs -- the hard way

Subject: Re: [boost] structured exceptions for UNIXs -- the hard way
From: Phil Endecott (spam_from_boost_dev_at_[hidden])
Date: 2011-09-21 12:37:12

Peter Foelsche wrote:
> On UNIXs one does not get around signals.
> They are used for everything.
> E.g. using memory mapped io is impossible without dealing with signals.
> E.g. somebody may edit the file which is mapped into your process
> thereby truncating it and invalidating some part of the memory.
> Or one may be writing into a sparse file via memory mapped io
> and the result of "out of disk space" is also a signal.
>
> Then there are such sick solutions as setjmp()/longjmp().
> Could they be packed into some class to enable some kind of structured exceptions on UNIXs?
>
>
> #include <setjmp.h>
> #include <vector>
>
>
> static std::vector<jmp_buf> s_sStack;
>
> static void signalHandler(void)
> {       if (s_sStack.size())
>         {       jmp_buf s = s_sStack.back();
>                 s_sStack.pop_back();
>                 longjmp(s);
>         }
> }
>
>
> struct CSetLongJmp
> {       CSetLongJmp(void)
>         {       s_sStack.push_back(jmp_buf());
>                 if (setjmp(s_sStack.back()))
>                           throw "something";
>         }
>         ~CSetLongJmp(void)
>         {       s_sStack.pop_back();
>         }
> };

There are a few problems with that, including longjmp() and std::vector 
not being signal-safe according to the standards.  I think that in 
practice you can probably get away with using them in most cases though.

Then there is this:

{
   CSetLongJmp a;
   NonTrivialType t;
   do_something_that_signals();
}

Is t's dtor called?

Finally, you have the problem that the stack frame in which setjmp() is 
called is already out of scope by the time that you try to longjmp() to 
it.  You can only do this by putting the actual setjmp() call inline.  
Macros can help with this sort of thing.

Regards,  Phil.