Announcing LEAF, a new error handling library suitable for low latency applications
LEAF (Low-latency Error Augmentation Framework) is a new error handling library which could possibly become the successor of Boost Exception, though LEAF can be used without exceptions too. Official documentation: https://zajo.github.io/leaf/ Features: - No dynamic memory allocations. - Associate objects of arbitrary types with any failure -- when it is initially reported or at a later time. - Compatible with std::error_code, errno and any other error handling API. - Use with or without exception handling. - Support for multi-thread programming. Emil
On 15/11/2018 11:19, Emil Dotchevski wrote:
LEAF (Low-latency Error Augmentation Framework) is a new error handling library which could possibly become the successor of Boost Exception, though LEAF can be used without exceptions too.
Official documentation: https://zajo.github.io/leaf/
Looks interesting. Does the implementation internally use thread-locals? Is it compatible with coroutines or fibers or other non-thread-based stacks?
On Wed, Nov 14, 2018 at 3:17 PM Gavin Lambert via Boost < boost@lists.boost.org> wrote:
On 15/11/2018 11:19, Emil Dotchevski wrote:
LEAF (Low-latency Error Augmentation Framework) is a new error handling library which could possibly become the successor of Boost Exception, though LEAF can be used without exceptions too.
Official documentation: https://zajo.github.io/leaf/
Looks interesting.
Does the implementation internally use thread-locals?
It uses thread_local raw pointers, one per error type. This is needed in order to decouple result<T> from the static type of error objects being propagated, which I consider critical, see https://zajo.github.io/leaf/#rationale. Is it compatible with coroutines or fibers or other non-thread-based stacks?
Good question. I'm not sure, but I'm interested to know what are the issues.
On 15/11/2018 12:29, Emil Dotchevski wrote:
It uses thread_local raw pointers, one per error type. This is needed in order to decouple result<T> from the static type of error objects being propagated, which I consider critical, see https://zajo.github.io/leaf/#rationale.
Is it compatible with coroutines or fibers or other non-thread-based stacks?
Good question. I'm not sure, but I'm interested to know what are the issues.
In general AFAIK, any use of thread-local storage is entirely incompatible with coroutines or fibers. (Unless the mechanisms for both cooperate with each other, which is theoretically possible but I'm not aware of it occurring in the wild.) (If you can guarantee that a given set of coroutines or fibers always executes within a single thread, then accessing thread-local objects created *outside* the coroutines is "safe" (they all access the same object, but non-concurrently; it can still lead to surprises if the object is mutable, however), but less so those created inside. Either way it's a little confusing.)
On Wed, Nov 14, 2018 at 5:19 PM Gavin Lambert via Boost < boost@lists.boost.org> wrote:
On 15/11/2018 12:29, Emil Dotchevski wrote:
It uses thread_local raw pointers, one per error type. This is needed in order to decouple result<T> from the static type of error objects being propagated, which I consider critical, see https://zajo.github.io/leaf/#rationale.
Is it compatible with coroutines or fibers or other non-thread-based stacks?
Good question. I'm not sure, but I'm interested to know what are the issues.
In general AFAIK, any use of thread-local storage is entirely incompatible with coroutines or fibers. (Unless the mechanisms for both cooperate with each other, which is theoretically possible but I'm not aware of it occurring in the wild.)
The LEAF machinery that is used for multi-thread support can probably be used as-is for coroutines as well. It should be possible to explicitly support coroutines context switching, which would be much faster, involving only setting raw pointers, possibly exactly one raw pointer.
On 11/14/2018 5:19 PM, Emil Dotchevski via Boost wrote:
LEAF (Low-latency Error Augmentation Framework) is a new error handling library which could possibly become the successor of Boost Exception, though LEAF can be used without exceptions too.
Official documentation: https://zajo.github.io/leaf/
Features:
- No dynamic memory allocations.
- Associate objects of arbitrary types with any failure -- when it is initially reported or at a later time.
- Compatible with std::error_code, errno and any other error handling API.
- Use with or without exception handling.
- Support for multi-thread programming.
Front and center, as in a general introduction: 1) Header files 2) Library dependencies 3) C++ standard level
Emil
On Wed, Nov 14, 2018 at 4:56 PM Edward Diener via Boost < boost@lists.boost.org> wrote:
On 11/14/2018 5:19 PM, Emil Dotchevski via Boost wrote:
LEAF (Low-latency Error Augmentation Framework) is a new error handling library which could possibly become the successor of Boost Exception, though LEAF can be used without exceptions too.
Official documentation: https://zajo.github.io/leaf/
Features:
- No dynamic memory allocations.
- Associate objects of arbitrary types with any failure -- when it is initially reported or at a later time.
- Compatible with std::error_code, errno and any other error handling API.
- Use with or without exception handling.
- Support for multi-thread programming.
Front and center, as in a general introduction:
1) Header files 2) Library dependencies 3) C++ standard level
Header-only, no dependency on any libraries, C++11. I'll update the documentation, thanks.
On 11/14/2018 8:03 PM, Emil Dotchevski via Boost wrote:
On Wed, Nov 14, 2018 at 4:56 PM Edward Diener via Boost < boost@lists.boost.org> wrote:
On 11/14/2018 5:19 PM, Emil Dotchevski via Boost wrote:
LEAF (Low-latency Error Augmentation Framework) is a new error handling library which could possibly become the successor of Boost Exception, though LEAF can be used without exceptions too.
Official documentation: https://zajo.github.io/leaf/
Features:
- No dynamic memory allocations.
- Associate objects of arbitrary types with any failure -- when it is initially reported or at a later time.
- Compatible with std::error_code, errno and any other error handling API.
- Use with or without exception handling.
- Support for multi-thread programming.
Front and center, as in a general introduction:
1) Header files 2) Library dependencies 3) C++ standard level
Header-only, no dependency on any libraries, C++11.
I'll update the documentation, thanks.
I meant with 1) to specify what header file(s) need to be included.
On Wed, Nov 14, 2018 at 5:51 PM Edward Diener via Boost < boost@lists.boost.org> wrote:
On 11/14/2018 8:03 PM, Emil Dotchevski via Boost wrote:
On Wed, Nov 14, 2018 at 4:56 PM Edward Diener via Boost < boost@lists.boost.org> wrote:
On 11/14/2018 5:19 PM, Emil Dotchevski via Boost wrote:
LEAF (Low-latency Error Augmentation Framework) is a new error handling library which could possibly become the successor of Boost Exception, though LEAF can be used without exceptions too.
Official documentation: https://zajo.github.io/leaf/
Features:
- No dynamic memory allocations.
- Associate objects of arbitrary types with any failure -- when it is initially reported or at a later time.
- Compatible with std::error_code, errno and any other error handling API.
- Use with or without exception handling.
- Support for multi-thread programming.
Front and center, as in a general introduction:
1) Header files 2) Library dependencies 3) C++ standard level
Header-only, no dependency on any libraries, C++11.
I'll update the documentation, thanks.
I meant with 1) to specify what header file(s) need to be included.
The documentation of each type and each function tells you which header you
need to include for it.
You could #include
Hi, Am 14.11.2018 23:19, schrieb Emil Dotchevski via Boost:
LEAF (Low-latency Error Augmentation Framework) is a new error handling library which could possibly become the successor of Boost Exception, though LEAF can be used without exceptions too.
Having had a short glance at the documentation, I missed the motivation. Seems like you think it is obvious, but I have not yet understood, what a library like this could add to exception handling or returning status codes, where exceptions are not acceptable. Up to now I've used exceptions for error handling. Why should I prefer to use your library instead, or additionally? Christof
participants (4)
-
Christof Donat -
Edward Diener -
Emil Dotchevski -
Gavin Lambert