pon., 4 maj 2020 o 02:41 Emil Dotchevski via Boost napisał(a):

Thanks for the interest.

On Sun, May 3, 2020 at 4:15 PM Andrzej Krzemienski via Boost < boost@lists.boost.org> 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... 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.

...

of documentation, unfair. If the goal of this comparison is to help

For a similar reason, I find the comparison with Boost.Outcome, at the end 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?t... (using exceptions)

Acknowledged. Regards, &rzej;

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

On 4/05/2020 20:29, Andrzej Krzemienski wrote:

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.

Coroutines can be used asynchronously without using threads. You just need to be careful to schedule them on an executor that is backed by only one thread, rather than a threadpool. In fact at least all the times that I have personally used coroutines, it's been in this manner -- when you're just managing multiple parallel tasks with a known-external delay (eg. slow network I/O), you don't really need a threadpool.

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