Re: [LEAF] The usage of TLS

From: Emil Dotchevski (emildotchevski_at_[hidden])
Date: 2020-05-05 21:39:41

The mechanism in LEAF for dealing with this sort of thing is to manually
activate/deactivate a leaf::context<>.

The general architecture of LEAF is this: there are one or more
leaf::context<E1, E2, ...> objects (think something similar to
std::tuple<E1, E2, ...>) at different error-handling scopes in the call
stack. When a context<E1, E2, ...> is activated, TLS pointers of the E1,
E2, ... types are pointed to the E1, E2, ... objects in that context. This
binds the context<> object to the calling thread and, from this point on,
the TLS pointers are used to transport the error objects when reported.
When control returns to the error-handling scope -- where the
leaf::context<> resides -- it is deactivated before errors are handled

Normally, users don't deal with leaf::context<> directly, but it is part of
the API and you can just make a context<>, activate it as needed to collect
error objects, then deactivate it and, if there was an error, move it
elsewhere to handle errors (if no error, you can just activate it again the
next time).

So, when I say it doesn't work well with coroutines, what I mean is it
won't "just work", not that you can't use it.

On Tue, May 5, 2020 at 6:59 AM Niall Douglas via Boost <
boost_at_[hidden]> wrote:

> On 04/05/2020 01:40, Emil Dotchevski via Boost wrote:
>
> > LEAF is not suitable for coroutines
>
> I cannot see any good reason why LEAF could not transport the current
> tree of LEAF state within a C++ Coroutine across kernel threads.
>
> Rough implementation:
>
> 1. Traverse the current LEAF state in the current C++ Coroutine.
>
> 2. Suspend the current C++ coroutine, resume an internal checking C++
> Coroutine.
>
> 3. Traverse the current LEAF state from within the internal checking C++
> Coroutine.
>
> 4. Compare this LEAF state with the previous one. If some of the LEAF
> state "escapes" the previous Coroutine, resume the original C++
> Coroutine and report failure, as this LEAF state cannot be transported
> between kernel threads.
>
> 5. Otherwise transporting LEAF state with the current C++ coroutine
> ought to be as simple as restamping the head TLS pointer to the current
> LEAF state when one resumes Coroutine execution in another kernel thread
> (i.e. squirrel away the head TLS pointer into the C++ coroutine frame,
> restore it upon resumption)
>
> 6. For convenience, wrap up all of the above into C++ coroutine
> awaitables which self-specialise when they see a T which is a LEAF
> result e.g. boost::leaf::awaitables::lazy<T>. You may find inspiration
> in the implementation code for outcome::awaitables::lazy<T>, as Outcome
> provides Outcome-specialising awaitable types.
>
>
> As an aside, Outcome did not support C++ Coroutines originally as I did
> not expect much demand for such support. I assumed that given the poor
> QoI of C++ Coroutines in all the major implementations nobody would
> deploy production software using them.
>
> It turns out I was wrong on that. Outcome + C++ Coroutines is
> surprisingly popular. And even I have ended up using it personally in
> test code (I still think Coroutines are not production ready).
>
> I would expect that if LEAF is accepted, you will see the same.
>
> Niall
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>