Re: [Boost-users] [fiber] Fiber context switching during stack unwinding...

Subject: Re: [Boost-users] [fiber] Fiber context switching during stack unwinding...
From: Oliver Kowalke (oliver.kowalke_at_[hidden])
Date: 2018-02-28 06:56:56

2018-02-28 6:57 GMT+01:00 Stian Zeljko Vrba via Boost-users <
boost-users_at_[hidden]>:

> Hi,
>
>
> The documentation for boost context contains the following warning: "Do
> not jump from inside a catch block and then re-throw the exception in
> another continuation. "
>
>
> It's on this page: http://www.boost.org/doc/libs/1_66_0/libs/context/
> doc/html/context/cc.html
>

+1

> ------------------------------
> *From:* Boost-users <boost-users-bounces_at_[hidden]> on behalf of
> Oliver Seiler via Boost-users <boost-users_at_[hidden]>
> *Sent:* Wednesday, February 28, 2018 6:45:16 AM
> *To:* boost-users_at_[hidden]
> *Cc:* Oliver Seiler
> *Subject:* [Boost-users] [fiber] Fiber context switching during stack
> unwinding...
>
> (Hopefully I'm not writing an essay for something that is a
> gcc/libstdc++/Linux bug)
>
> I've been using Boost.Context for a number of years now, to do something
> similar to what Boost.Fiber does. We recently upgraded our development
> target environment to Debian 9 (gcc 6.3), and moved up to Boost 1.62.0, so
> I've been looking at Boost.Fiber to replace how we're using Boost.Context
> (because it looks like it could greatly simplify our code, among other
> things).
> One thing I ran into with Boost.Context was that it interacted in some
> interesting ways with exception handling, and I haven't really seen any
> discussion about it. Specifically, switching contexts with an active
> exception (so during stack unwinding, or in a catch block) would result in
> weird behaviour in the other context (std::uncaught_exception() returning
> true, std::current_exception() returning the exception from the other
> context, try/catches in the new context causing new problems when switching
> back to the original context which is in the middle of stack unwinding,
> etc).
>
> I chalked that up to limitations of the context switching, though I
> haven't seen any mention of avoiding context switches with active
> exceptions; presumably this is some interaction with gcc's exception
> implementation, and would maybe need support from libunwind to save/restore
> the exception state (I don't recall if I checked if clang produced similar
> results, though I'll probably give it a go when I have the chance). So I
> wasn't surprised when I ran into similar problems with Boost.Fiber.
>
> I am wondering why this aspect of usage isn't discussed in any of the
> documentation; it would be nice if these libraries could work well with
> language features like exceptions, but I understand that the language spec
> doesn't really speak to the stack switching happening under-the-hood. It
> actually wouldn't surprise me that this wasn't even a problem in all
> environments, and just happens to be an artifact of the Linux
> implementation, but then we're either talking about unspecified or
> undefined behaviour, but would be nice to know. Even in the documents going
> through the C++ standards committee I don't see much mention of how things
> like coroutines should interact with something like
> std::current_exception() (perhaps because it is assumed to "just work" and
> doesn't need additional comment?)
>
> Anyone else ever run into issues related to this? Seems like any use of
> RAII for exception handling would easily run into problems. Mostly I've
> just found ways to work around it (e.g., not allowing the context switch if
> std::uncaught_exception() or std::current_exception() indicate it would be
> unsafe to do so, typically by throwing another exception) but this tends to
> make libraries harder to use correctly (e.g., can't really allow context
> switching in a destructor, or in a function called from a destructor, etc).
>
> Cheers
> Oliver
>

you could try to store the exeception in a std::exception_ptr ... leave the
catch clause and then use the std::exception_ptr to transport the exception
to another context (via jump)