| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
Nothing used it, and it has some semantic complexity.
(see
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/2722#note_3149591
)
|
| |
|
|
|
|
| |
The Waker::clone_from implementation uses Waker::will_wake
to avoid unnecessarily cloning a Waker that it already
has a copy of.
|
| |
|
|
|
|
|
|
|
|
|
| |
Cancellation is now fallable, which allows us to detect attempts
to cancel which cannot work.
We now guarantee that when you try to cancel a `Cancel<F>` future,
either the cancel operation will succeed, or the future will return
(or will have already returned) Ok(), but not both, and not neither.
Closes #818.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Having this in the `tor-async-utils` crate prevents us from doing both
of the following without introducing a circular dependency:
* using it in `tor-rtmock` (which we currently do, particularly in
tests).
* using `tor-rtmock` to test things in `tor-async-utils`. We don't do
this yet, but it is generally sensible to do so. In particular we
want to move the `stream_peak` module there, which is currently tested
with `tor-rtmock`.
Moving this into its own crate avoids this circular dependency.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
|
|
Ordinarily you can cancel a future just by dropping it, but we'll
want the ability to cancel futures that we no longer own (because we
gave them to a `FuturesUnordered`).
|
