introduce unifex::async_resource#475
Draft
janondrusek wants to merge 141 commits intofacebookexperimental:mainfrom
Draft
introduce unifex::async_resource#475janondrusek wants to merge 141 commits intofacebookexperimental:mainfrom
unifex::async_resource#475janondrusek wants to merge 141 commits intofacebookexperimental:mainfrom
Conversation
Contributor
janondrusek
commented
Nov 4, 2022
- async_destroy CPO
- returns a ptr-like object
…/master Merge from master to unstable
…/unstable Merge from unstable to broken-stdlib
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
…/master Merge from master
…/unstable Merge from unstable
…/master Merge from master
…/master Merge from master
…/create-sender add unifex::create for trivially wrapping a C-style async API, fixes facebookexperimental#294
* simpler than `unifex::v1::async_scope` (`nest()` and `join()`) * does not support cancellation Co-authored-by: Ian Petersen <ispeters@gmail.com> Co-authored-by: Ian Petersen <ispeters@gmail.com>
PR facebookexperimental#454 missed including `<unifex/continuations.hpp>` in `when_all_range.hpp` so let's fix that.
The existing operation state for `let_value_with` assumes that its *Sender* will always be an rvalue; this diff fixes the operation state's constructor to support lvalue *Senders*.
`unifex::nest()` is a CPO that delegates to either a `tag_invoke` customization taking a *Sender* and a "scope" reference, or to a member function on the given scope that takes a *Sender*. This diff wires `unifex::nest()` to the `nest()` member function on `v2::async_scope` and to the `attach()` member function on `v1::async_scope`.
…tal#470) This diff introduces a new algorithm, `unifex::spawn_detached()`. `spawn_detached` takes a sender, an "async scope", and an optional allocator. It nests the sender in the scope with `unifex::nest`, allocates and operation state using the allocator, and starts that operation. The given async scope may be anything that `nest()` supports, which currently includes both `v1::async_scope` and `v2::async_scope`.
With the introduction of `unifex::nest()` and `unifex::spawn_detached()`, we can simplify the implementation of `v1::async_scope`. This diff changes its `detached_spawn` to delegate to `unifex::spawn_detached()`.
f22482c to
1161dfd
Compare
1161dfd to
80dd528
Compare
…acebookexperimental#477) * Disable continuation visitations by default for binary size savings * Add unifex prefix to macro and fix async_trace * Fix unused variable error * Change ordering of field initializations * Address comments
* gcc 9,10 * clang 10,11,12
* rm absl and related polyfills * optional * utility * variant
This diff adds some `//` comments to the ends of some lines and then runs the result through `clang-format`.
…l#483) When trying to nest a `let_value_with_stop_token()` *Sender* inside a `unifex::v2::async_scope`, I discovered there were problems checking the constraints on a `const Sender&` when `Sender` was a `let_value_with_stop_token` *Sender* constructed with a `mutable` lambda. This diff fixes the above scenario and includes a regression test. The fixes include: - fixing the type calculations on `SuccessFactory` (e.g. we invoke an lvalue reference not an rvalue reference) - correcting the `noexcept` calculations (e.g. although we *construct* our copy of the `SuccessorFactory` in a value category-sensitive way, we always *invoke* the factory as a mutable lvalue) - standardizing value category casts (i.e. using `std::move()` for moves and `static_cast<DestType&&>()` for forwards) - adding some `static_assert`s to confirm the validity of the above fixes - made the operation state immovable
…mental#484) While writing `unifex::spawn_future()`, I discovered that waiting until the destructor of the `v2::async_scope`'s `nest()` operation to drop the scope reference is too late (it led to hangs). This diff adds an internal receiver to the nest operation so we can detect when the operation is complete (which is likely before the operation state is destroyed) and drop the reference as soon as we reach that state.
80cb272 to
77bc100
Compare
77bc100 to
434ad64
Compare
434ad64 to
3622a98
Compare
- async_destroy CPO - returns a `unique_ptr`-like object
3622a98 to
123ae48
Compare
Contributor
|
Hi all! :-)
I'm trying to wrap my head around the implications of this change. IIUC, "async resource" is a concept, and that there are generic algorithms/utilities that get constrained with it, and multiple concrete types that model the concept. One such generic utility is |
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.