libunifex
libunifex copied to clipboard
Unified Executors
any reason why the below code does not compile. It compiles fine if I use sync_wait instead async_scope. Basically, I wanted to capture any exception that occurred through the value...
The when_all_range algorithm is similar to when_all but takes in a dynamic vector of senders.
`values` construction may throw. Use `UNIFEX_TRY {} UNIFEX_CATCH {}` to forward `current_exception` to `set_error`. https://github.com/facebookexperimental/libunifex/blob/99b39667e04f6f12ef1bed9a5c69312cc1a9abd3/include/unifex/let_error.hpp#L92
See #397 which introduced the `variant_sender` algorithm
I was playing with the following example, and noticed it passes on GCC 10, clang 12,13,14, but fails to compile on GCC 11, 12. ``` let_done( let_error( []() -> task...
I think it's really bad that mutex serialize all waiters to single thread. I think unlock should be something like this, if it async: Executor.Schedule(after unlock code); ExecuteHere(next critical section)...
Now async_mutex is provided in libunifex. Is it possible to provide async_shared_mutex, just like std::shared_mutex? ```cpp async_shared_mutex mu; co_await mu.lock_shared(); // some read operation mu.unlock_shared(); co_await mu.lock(); // some write...
The via() and on() algorithms currently take a sender that represents the execution context transition rather than taking the scheduler. This means the caller needs to explicitly call `schedule(s)` to...
I wrote a very simple test due to the doc, call on(scheduler1) and then on(scheduler2), but I found all code run on scheduler1. What's wrong, please? ```c++ #include #include #include...
This should avoid the use of thread_local but should also allow us to detect whether a context's run() method is executing regardless of whether there is a nested io_uring_context::run() method...