Re: [LEAF] The usage of TLS

From: Andrzej Krzemienski (akrzemi1_at_[hidden])
Date: 2020-05-04 08:29:46

pon., 4 maj 2020 o 02:41 Emil Dotchevski via Boost <boost_at_[hidden]>
napisał(a):

> Thanks for the interest.
>
> On Sun, May 3, 2020 at 4:15 PM Andrzej Krzemienski via Boost <
> boost_at_[hidden]> wrote:
>
> > It can service the environments where TLS is affordable.
>
>
> You're assuming that the use of TLS pointers to error objects in LEAF,
> moving error objects directly to the scope where they are needed, bypassing
> return values and stack frames, is less efficient than transporting them in
> return values. Depending on your platform and your error object types, it
> could go either way.
>

I am sorry. It was a bad choice of words on my side. I did not mean to
imply that the usage of TLS would make the library go slower compared to
alternatives. What I was trying to say is that on some platforms LEAF would
not compile because of the missing TLS support, and that I would only
discover it after having invested a significant amount of time, because the
documentation does not declare it up front.

These are the guidelines that I learned from Robert Ramey's talk on
documenting a library (https://www.youtube.com/watch?v=ACeNgqBKL7E). As a
potential user I need to learn in no more than 5 minutes: what the library
does, how I will use it (LEAF documentation does it perfectly), and what
are the requirements. For the last point I would expect to see: "your
platform needs to support TLS, and your program cannot use coroutines in
asynchronous manner." IOW: high-level design trade-offs should be
documented up front.

>
> Separately, LEAF can transport any number of error objects of arbitrary
> types without dynamic allocations. If you need to do this with a
> conventional result<T> implementation, you'll be allocating memory. That
> may be as much of a showstopper as unavailability of TLS could be for LEAF.
>

I acknowledge this. And I think this part is nicely outlined in the
documentation. My critique was not about the trade-offs that the library
does. It was about not documenting it clearly.

As a side note, the choice of providing efficient stack storage for
arbitrary number and kind of error objects does not necessarily require the
usage of STL. An alternative described in
https://www.research.ed.ac.uk/portal/files/78829292/low_cost_deterministic_C_exceptions_for_embedded_systems.pdf
creates a similar stack storage, but instead passes a pointer to it to
every function that needs to report a failure using this mechanism. But the
authors are implementing it as a compiler extension, and this choice to
pass the pointer to the storage to all function may not be suitable for a
library implementation. So the trade-off here is: TLS in order to preserve
the normal set and type of function inputs.

> For a similar reason, I find the comparison with Boost.Outcome, at the end
> > of documentation, unfair. If the goal of this comparison is to help
> people
> > decide which library is best suited for them, LEAF or Outcome, the usage
> or
> > non-usage of TLS is an important factor.
> >
>
> It's important but not in terms of efficiency, only in terms of
> availability and suitability. LEAF is not suitable for coroutines or GPUs
> (though GPU code doesn't need much in terms of error handling anyway).
>

Regarding platforms that do not support TLS, I will learn about it the hard
way when I try to compile the library, which is enough to avoid any bugs.

However, not being suitable for coroutines is more serious, because the
library will compile and maybe even execute as expected in simple test
cases. And it may give false impression that this just works. I would
recommend putting a visible note in the documentation saying that the
library is using TLS and therefore is not suitable for programs that use
coroutines for asynchronous calls.

> LEAF works well with async code based on threads, see:
>
>
> https://github.com/zajo/leaf/blob/master/examples/capture_in_result.cpp?ts=4
> (without
> exceptions)
>
>
> https://github.com/zajo/leaf/blob/master/examples/capture_in_exception.cpp?ts=4
> (using
> exceptions)
>

Acknowledged.

Regards,
&rzej;

> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>