libunifex

libunifex copied to clipboard

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...

abhilashraju

The when_all_range algorithm is similar to when_all but takes in a dynamic vector of senders.

AnujYamdagni

`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

janondrusek

rewrite `just_void_or_done` in terms of `variant_sender`

1

See #397 which introduced the `variant_sender` algorithm

janondrusek

tag_invoke related compiler error with gcc >= 11

4

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...

ccotter

Mutex::unlock serialize code after it

10

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)...

MBkkt

provide async_shared_mutex

1

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...

wtudio

The via() and on() algorithms should take a scheduler

3

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...

lewissbaker

question of on

3

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...

franktea

io_uring_context should use std::atomic<std:: thread::id> instead of thread_local to determine if currently on the I/O thread

1

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...

lewissbaker