-
Notifications
You must be signed in to change notification settings - Fork 186
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
This commit implements scheduler affinity -- aka "sticky" scheduling -- in `unifex::task<>`. The idea is that it is impossible for a child operation to cause the current coroutine to resume on the wrong execution context. * `task<>`-based coroutines track and propagate the current scheduler * `at_coroutine_exit` remembers current scheduler from when the cleanup action is scheduled * `schedule` always returns an instance of `sender_for<schedule, the_sender>`, which is also a `scheduler_provider` * scheduler affinity when co_await-ing senders in a `task<>`-returning coroutine * scheduler affinity when co_await-ing awaitables in a `task<>`-returning coroutine * awaitables and senders that are `blocking_kind::always_inline` don't get a thunk * More senders and awaitables support compile-time blocking queries * `co_await schedule(sched)` is magic in a `task<>`-returning coroutine: it changes execution context and schedules a cleanup action to transition back to the original scheduler Move implementation of special co_await behavior of scheduler senders out of task.hpp Hoist untyped RAII containers for coroutine_handle<> out of task<> and its awaiter (#329) While looking at the binary size impact of adopting coroutines with `unifex::task<>`, I noticed that a number of operations on `coroutine_handle<T>` are expressed in `unifex::task<>` as if they depend on `T` when they don't. The consequence is extra code. This diff creates a `coro_holder` class that uniquely owns a `coroutine_handle<>` and makes `unifex::task<>` inherit from it. We technically lose some type safety, but it's still correct by construction. This change saves about 1.5 kilobytes in one of our apps. Similar to the above, I noticed binary duplication due to false template parameter dependencies in `unifex::task<>`'s awaiter type. This diff hoists a non-type-specific RAII container for a `coroutine_handle<>` that stores the handle as a `std::uintptr_t` so that `task`'s awaiter can use the low bit as a dirty flag. This change saves another ~1.5 kilobytes in one of our apps. Fix scheduler affinity (#405) * Fix scheduler affinity We have been storing a `task<>`'s scheduler as an `any_scheduler_ref`, which has proven to be a source of use-after-free bugs. This change switches all the `any_scheduler_ref`s to `any_scheduler`s, fixing the lifetime issues. Make task<>'s thunk-on-resume unstoppable (#495) * Make task<>'s thunk-on-resume unstoppable When awaiting an async Sender that swallows done signals (such as let_done(never_sender{}, just)), the user-level code looks like it swallows done signals: ``` // never cancels co_await let_done(never_sender{}, just); ``` However, `task<>`'s Scheduler affinity implementation transforms the above code into this: ``` co_await typed_via(let_done(never_sender{}, just), <current scheduler>); ``` The `schedule()` operation inside the injected `typed_via` can emit done if the current stop token has had stop requested, leading to very non-obvious cancellation behaviour that can't be worked around. This diff introduces a pair of regression tests that capture the above scenario, and the analogous scenario of awaiting an async Awaitable that completes with done. The next diff will fix these failing tests. * Change task<>'s thunk-on-resume to be unstoppable This diff fixes the broken tests in the previous diff. Respect blocking_kind in `let_value()` (#381) * `let_value()` would always assume `blocking_kind::maybe`, which results in potentially unnecessary reschedule on resumption * replicate `blocking_kind` customization from `finally()` fix `variant_sender` blocking kind (#474) add `unifex::v2::async_scope` (#463) * simpler than `unifex::v1::async_scope` (`nest()` and `join()`) * does not support cancellation fixing linter error (#414) move deduction guide to namespace scope for gcc-10 in scheduler concept, check copy_constructability after requiring call to schedule() work around gcc-10 bugs avoid warning about missing braces in initializer back out change to awaiter_type_t Co-authored-by: Eric Niebler <[email protected]> Co-authored-by: Ian Petersen <[email protected]> Co-authored-by: Ondrej Lehecka <[email protected]>
- Loading branch information
1 parent
63ce7c6
commit 69df6dc
Showing
39 changed files
with
1,547 additions
and
304 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.