Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

task: add task IDs #4630

Merged
merged 14 commits into from Apr 25, 2022
Merged

task: add task IDs #4630

merged 14 commits into from Apr 25, 2022

Conversation

hawkw
Copy link
Member

@hawkw hawkw commented Apr 20, 2022

Motivation

PR #4538 adds a prototype implementation of a JoinMap API in
tokio::task. In this comment on that PR, @carllerche pointed out
that a much simpler JoinMap type could be implemented outside of
tokio (either in tokio-util or in user code) if we just modified
JoinSet to return a task ID type when spawning new tasks, and when
tasks complete. This seems like a better approach for the following
reasons:

  • A JoinMap-like type need not become a permanent part of tokio's
    stable API
  • Task IDs seem like something that could be generally useful outside of
    a JoinMap implementation

Solution

This branch adds a tokio::task::Id type that uniquely identifies a
task relative to all other spawned tasks. Task IDs are assigned
sequentially based on an atomic usize counter of spawned tasks.

In addition, I modified JoinSet to add a join_with_id method that
behaves identically to join_one but also returns an ID. This can be
used to implement a JoinMap type.

Note that because join_with_id must return a task ID regardless of
whether the task completes successfully or returns a JoinError, I've
also changed JoinError to carry the ID of the task that errored, and
added a JoinError::id method for accessing it. Alternatively, we could
have done one of the following:

  • have join_with_id return Option<(Id, Result<T, JoinError>)>, which
    would be inconsistent with the return type of join_one (which we've
    already bikeshedded over once...)
  • have join_with_id return Result<Option<(Id, T)>, (Id, JoinError)>>,
    which just feels gross.

I thought adding the task ID to JoinError was the nicest option, and
is potentially useful for other stuff as well, so it's probably a good API to
have anyway.

Closes #4538

@hawkw hawkw self-assigned this Apr 20, 2022
@github-actions github-actions bot added the R-loom Run loom tests on this PR label Apr 20, 2022
@hawkw hawkw added C-enhancement Category: A PR with an enhancement or bugfix. A-tokio Area: The main tokio crate M-task Module: tokio/task and removed R-loom Run loom tests on this PR labels Apr 20, 2022
@Darksonn
Copy link
Contributor

These IDs aren't necessarily guaranteed to be unique since the same address can be reused after being deallocated. I remember this being considered important for the standard library thread IDs for some reason.

@hawkw
Copy link
Member Author

hawkw commented Apr 20, 2022

These IDs aren't necessarily guaranteed to be unique since the same address can be reused after being deallocated. I remember this being considered important for the standard library thread IDs for some reason.

Yeah, I added a note in the docs stating that uniqueness is not guaranteed after a task has completed:

/// # Notes
///
/// - Task IDs are unique relative to other *currently running* tasks. When a
/// task completes, the same ID may be used for another task.
/// - Task IDs are *not* sequential, and do not indicate the order in which
/// tasks are spawned, what runtime a task is spawned on, or any other data.

If we're concerned about this, we could alternatively switch to sequential IDs, but I thought that the guarantees offered by using an address would be sufficient for implementing a JoinMap and similar things, given that the task is not deallocated until its output is consumed, and that it was nice to not have to carry around an extra ID field. Also, we don't have to worry about a counter wrapping and clobbering the IDs of tasks that are still active this way, which would be a concern with sequential IDs.

I could change the implementation, though, if we don't think the uniqueness guarantees of addresses are strong enough.

@hawkw
Copy link
Member Author

hawkw commented Apr 20, 2022

(i agree that a 64-bit task counter is probably not going to wrap in most reasonable programs, but...idk)

@Darksonn
Copy link
Contributor

I don't think you could get it to wrap even in unreasonable programs.

@github-actions github-actions bot added the R-loom Run loom tests on this PR label Apr 21, 2022
@hawkw
Copy link
Member Author

hawkw commented Apr 21, 2022

@Darksonn I've changed this to assign task IDs based on a sequential counter, so they should remain unique after a task is deallocated. My main concern (more than the potential for IDs to wrap) was not wanting to put an additional field in the task header, but I realized this wasn't actually necessary and the ID can just go in the JoinHandle itself, and in the task core so that it can be used to populate JoinErrors. LMKWYT?

/// [unstable]: crate#unstable-features
#[cfg_attr(docsrs, doc(cfg(all(feature = "rt", tokio_unstable))))]
#[cfg_attr(not(tokio_unstable), allow(unreachable_pub))]
// TODO(eliza): there's almost certainly no reason not to make this `Copy` as well...
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we should probably just derive Copy as well, but i didn't add it out of an abundance of caution for forwards-compatibility. anyone have a problem with deriving Copy for these?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Doesn't std have Id actually hold an Arc? While i don't think we want to do this, we may want to wait hold off on Copy.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But, I also don't care that much, if y'all think Copy is good, do it.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Doesn't std have Id actually hold an Arc? While i don't think we want to do this, we may want to wait hold off on Copy.

Yeah, this is why I didn't add Copy to this, so that we could reserve the right to change the repr however we want to later. I just think we are probably not going to actually do that. I'll hold off on making that commitment for now.

tokio/src/runtime/task/mod.rs Outdated Show resolved Hide resolved
@@ -120,6 +123,7 @@ impl<T: Future, S: Schedule> Cell<T, S> {
stage: CoreStage {
stage: UnsafeCell::new(Stage::Running(future)),
},
task_id,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if we store this, it should probably be in the trailer no?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The header needs to stay under a cache line, but as long as CI passes, it should be good to go: https://github.com/tokio-rs/tokio/blob/master/tokio/src/runtime/task/core.rs#L266

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It has to be stored somewhere in the task structure because it's passed to poll_future and cancel_task in order to populate a JoinError:

match res {
Ok(()) => {
stage.store_output(Err(JoinError::cancelled(id)));
}
Err(panic) => {
stage.store_output(Err(JoinError::panic(id, panic)));
}
}

and
Err(panic) => Err(JoinError::panic(id, panic)),

It could go in the Core or in the Trailer --- my sense was that the Core contained data that's used when actually polling the task, and the trailer contains data that's only used when the task completes. Technically the Id is consumed only on completion, but inside of the functions that are called on every poll, so we would need to dereference the trailer in those functions to get the ID, and we don't currently dereference the trailer on polls.

I agree that it shouldn't go in the header; it currently doesn't.

Copy link
Member

@carllerche carllerche left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, I had a few suggestions, but none are blocking at this point.

@hawkw
Copy link
Member Author

hawkw commented Apr 22, 2022

82787d5 also adds the runtime generated task IDs to the task tracing spans, when tracing is enabled. Unfortunately, this means the IDs have to be generated much higher up the callstack so they can be added to the tracing spans, and then passed down to the actual task machinery. But, I think this is worth it to be able to record that data.

## Motivation

PR #4538 adds a prototype implementation of a `JoinMap` API in
`tokio::task`. In [this comment][1] on that PR, @carllerche pointed out
that a much simpler `JoinMap` type could be implemented outside of
`tokio` (either in `tokio-util` or in user code) if we just modified
`JoinSet` to return a task ID type when spawning new tasks, and when
tasks complete. This seems like a better approach for the following
reasons:

* A `JoinMap`-like type need not become a permanent part of `tokio`'s
  stable API
* Task IDs seem like something that could be generally useful outside of
  a `JoinMap` implementation

## Solution

This branch adds a `tokio::task::Id` type that uniquely identifies a
task relative to all currently spawned tasks. The ID is internally
represented as a `NonZeroUsize` that's based on the address of the
task's header. I thought that it was better to use addresses to generate
IDs than assigning sequential IDs to tasks, because a sequential ID
would mean adding an additional usize field to the task data
somewhere, making it a word bigger. I've added methods to `JoinHandle`
and `AbortHandle` for returning a task's ID.

In addition, I modified `JoinSet` to add a `join_with_id` method that
behaves identically to `join_one` but also returns an ID. This can be
used to implement a `JoinMap` type.

Note that because `join_with_id` must return a task ID regardless of
whether the task completes successfully or returns a `JoinError` (in
order to ensure that dead tasks are always cleaned up from a map), it
inverts the ordering of the `Option` and `Result` returned by `join_one`
--- which we've bikeshedded about a bit [here][2]. This makes the
method's return type inconsistent with the existing `join_one` method,
which feels not great. As I see it, there are three possible solutions
to this:

* change the existing `join_one` method to also swap the `Option` and
  `Result` nesting for consistency.
* change `join_with_id` to return `Result<Option<(Id, T)>, (Id,
  JoinError)>>`, which feels gross...
* add a task ID to `JoinError` as well.

[1]: #4538 (comment)
[2]: #4335 (comment)
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
This commit adds the runtime generated task IDs to the task `tracing`
spans, when tracing is enabled. Unfortunately, this means the IDs have
to be generated much higher up the callstack so they can be added to the
tracing spans, and then passed down to the actual task machinery. But, I
think this is worth it to be able to record that data.

Signed-off-by: Eliza Weisman <eliza@buoyant.io>
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
@Darksonn
Copy link
Contributor

Does this expose an API to get the id of the current task? That's a common feature request.

Copy link
Member

@carllerche carllerche left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM 👍 thanks

@hawkw
Copy link
Member Author

hawkw commented Apr 25, 2022

Does this expose an API to get the id of the current task? That's a common feature request.

It does not currently, but it ought to be possible to add that in a subsequent PR.

Signed-off-by: Eliza Weisman <eliza@buoyant.io>
Copy link
Contributor

@Noah-Kennedy Noah-Kennedy left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM!

@hawkw hawkw enabled auto-merge (squash) April 25, 2022 17:16
@hawkw hawkw merged commit 1d3f123 into master Apr 25, 2022
@hawkw hawkw deleted the eliza/ids branch April 25, 2022 17:31
@hawkw hawkw mentioned this pull request Apr 25, 2022
hawkw added a commit that referenced this pull request Apr 26, 2022
## Motivation

In many cases, it is desirable to spawn a set of tasks associated with
keys, with the ability to cancel them by key. As an example use case for
this sort of thing, see Tower's [`ReadyCache` type][1].

Now that PR #4530 adds a way of cancelling tasks in a
`tokio::task::JoinSet`, we can implement a map-like API based on the
same `IdleNotifiedSet` primitive.

## Solution

This PR adds an implementation of a `JoinMap` type to
`tokio_util::task`, using the `JoinSet` type from `tokio::task`, the
`AbortHandle` type added in #4530, and the new task IDs added in #4630.

Individual tasks can be aborted by key using the `JoinMap::abort`
method, and a set of tasks whose key match a given predicate can be
aborted using `JoinMap::abort_matching`.

When tasks complete, `JoinMap::join_one` returns their associated key
alongside the output from the spawned future, or the key and the
`JoinError` if the task did not complete successfully.

Overall, I think the way this works is pretty straightforward; much of
this PR is just API boilerplate to implement the union of applicable
APIs from `JoinSet` and `HashMap`. Unlike previous iterations on the
`JoinMap` API (e.g. #4538), this version is implemented entirely in
`tokio_util`, using only public APIs from the `tokio` crate. Currently,
the required `tokio` APIs are unstable, but implementing `JoinMap` in
`tokio-util` means we will never have to make stability commitments for
the `JoinMap` API itself.

[1]: https://github.com/tower-rs/tower/blob/master/tower/src/ready_cache/cache.rs

Signed-off-by: Eliza Weisman <eliza@buoyant.io>
hawkw added a commit that referenced this pull request Apr 27, 2022
# 1.18.0 (April 27, 2022)

This release adds a number of new APIs in `tokio::net`, `tokio::signal`, and
`tokio::sync`. In addition, it adds new unstable APIs to `tokio::task` (`Id`s
for uniquely identifying a task, and `AbortHandle` for remotely cancelling a
task), as well as a number of bugfixes.

### Fixed

- blocking: add missing `#[track_caller]` for `spawn_blocking` ([#4616])
- macros: fix `select` macro to process 64 branches ([#4519])
- net: fix `try_io` methods not calling Mio's `try_io` internally ([#4582])
- runtime: recover when OS fails to spawn a new thread ([#4485])

### Added

- macros: support setting a custom crate name for `#[tokio::main]` and
  `#[tokio::test]` ([#4613])
- net: add `UdpSocket::peer_addr` ([#4611])
- net: add `try_read_buf` method for named pipes ([#4626])
- signal: add `SignalKind` `Hash`/`Eq` impls and `c_int` conversion ([#4540])
- signal: add support for signals up to `SIGRTMAX` ([#4555])
- sync: add `watch::Sender::send_modify` method ([#4310])
- sync: add `broadcast::Receiver::len` method ([#4542])
- sync: add `watch::Receiver::same_channel` method ([#4581])
- sync: implement `Clone` for `RecvError` types ([#4560])

### Changed

- update `nix` to 0.24, limit features ([#4631])
- update `mio` to 0.8.1 ([#4582])
- macros: rename `tokio::select!`'s internal `util` module ([#4543])
- runtime: use `Vec::with_capacity` when building runtime ([#4553])

### Documented

- improve docs for `tokio_unstable` ([#4524])
- runtime: include more documentation for thread_pool/worker ([#4511])
- runtime: update `Handle::current`'s docs to mention `EnterGuard` ([#4567])
- time: clarify platform specific timer resolution ([#4474])
- signal: document that `Signal::recv` is cancel-safe ([#4634])
- sync: `UnboundedReceiver` close docs ([#4548])

### Unstable

The following changes only apply when building with `--cfg tokio_unstable`:

- task: add `task::Id` type ([#4630])
- task: add `AbortHandle` type for cancelling tasks in a `JoinSet` ([#4530],
  [#4640])
- task: fix missing `doc(cfg(...))` attributes for `JoinSet` ([#4531])
- task: fix broken link in `AbortHandle` RustDoc ([#4545])
- metrics: add initial IO driver metrics ([#4507])

[#4616]: #4616
[#4519]: #4519
[#4582]: #4582
[#4485]: #4485
[#4613]: #4613
[#4611]: #4611
[#4626]: #4626
[#4540]: #4540
[#4555]: #4555
[#4310]: #4310
[#4542]: #4542
[#4581]: #4581
[#4560]: #4560
[#4631]: #4631
[#4582]: #4582
[#4543]: #4543
[#4553]: #4553
[#4524]: #4524
[#4511]: #4511
[#4567]: #4567
[#4474]: #4474
[#4634]: #4634
[#4548]: #4548
[#4630]: #4630
[#4530]: #4530
[#4640]: #4640
[#4531]: #4531
[#4545]: #4545
[#4507]: #4507
hawkw added a commit that referenced this pull request Apr 27, 2022
# 1.18.0 (April 27, 2022)

This release adds a number of new APIs in `tokio::net`, `tokio::signal`, and
`tokio::sync`. In addition, it adds new unstable APIs to `tokio::task` (`Id`s
for uniquely identifying a task, and `AbortHandle` for remotely cancelling a
task), as well as a number of bugfixes.

### Fixed

- blocking: add missing `#[track_caller]` for `spawn_blocking` ([#4616])
- macros: fix `select` macro to process 64 branches ([#4519])
- net: fix `try_io` methods not calling Mio's `try_io` internally ([#4582])
- runtime: recover when OS fails to spawn a new thread ([#4485])

### Added

- macros: support setting a custom crate name for `#[tokio::main]` and
  `#[tokio::test]` ([#4613])
- net: add `UdpSocket::peer_addr` ([#4611])
- net: add `try_read_buf` method for named pipes ([#4626])
- signal: add `SignalKind` `Hash`/`Eq` impls and `c_int` conversion ([#4540])
- signal: add support for signals up to `SIGRTMAX` ([#4555])
- sync: add `watch::Sender::send_modify` method ([#4310])
- sync: add `broadcast::Receiver::len` method ([#4542])
- sync: add `watch::Receiver::same_channel` method ([#4581])
- sync: implement `Clone` for `RecvError` types ([#4560])

### Changed

- update `nix` to 0.24, limit features ([#4631])
- update `mio` to 0.8.1 ([#4582])
- macros: rename `tokio::select!`'s internal `util` module ([#4543])
- runtime: use `Vec::with_capacity` when building runtime ([#4553])

### Documented

- improve docs for `tokio_unstable` ([#4524])
- runtime: include more documentation for thread_pool/worker ([#4511])
- runtime: update `Handle::current`'s docs to mention `EnterGuard` ([#4567])
- time: clarify platform specific timer resolution ([#4474])
- signal: document that `Signal::recv` is cancel-safe ([#4634])
- sync: `UnboundedReceiver` close docs ([#4548])

### Unstable

The following changes only apply when building with `--cfg tokio_unstable`:

- task: add `task::Id` type ([#4630])
- task: add `AbortHandle` type for cancelling tasks in a `JoinSet` ([#4530],
  [#4640])
- task: fix missing `doc(cfg(...))` attributes for `JoinSet` ([#4531])
- task: fix broken link in `AbortHandle` RustDoc ([#4545])
- metrics: add initial IO driver metrics ([#4507])

[#4616]: #4616
[#4519]: #4519
[#4582]: #4582
[#4485]: #4485
[#4613]: #4613
[#4611]: #4611
[#4626]: #4626
[#4540]: #4540
[#4555]: #4555
[#4310]: #4310
[#4542]: #4542
[#4581]: #4581
[#4560]: #4560
[#4631]: #4631
[#4582]: #4582
[#4543]: #4543
[#4553]: #4553
[#4524]: #4524
[#4511]: #4511
[#4567]: #4567
[#4474]: #4474
[#4634]: #4634
[#4548]: #4548
[#4630]: #4630
[#4530]: #4530
[#4640]: #4640
[#4531]: #4531
[#4545]: #4545
[#4507]: #4507
hawkw added a commit that referenced this pull request Apr 27, 2022
# 1.18.0 (April 27, 2022)

This release adds a number of new APIs in `tokio::net`, `tokio::signal`, and
`tokio::sync`. In addition, it adds new unstable APIs to `tokio::task` (`Id`s
for uniquely identifying a task, and `AbortHandle` for remotely cancelling a
task), as well as a number of bugfixes.

### Fixed

- blocking: add missing `#[track_caller]` for `spawn_blocking` ([#4616])
- macros: fix `select` macro to process 64 branches ([#4519])
- net: fix `try_io` methods not calling Mio's `try_io` internally ([#4582])
- runtime: recover when OS fails to spawn a new thread ([#4485])

### Added

- macros: support setting a custom crate name for `#[tokio::main]` and
  `#[tokio::test]` ([#4613])
- net: add `UdpSocket::peer_addr` ([#4611])
- net: add `try_read_buf` method for named pipes ([#4626])
- signal: add `SignalKind` `Hash`/`Eq` impls and `c_int` conversion ([#4540])
- signal: add support for signals up to `SIGRTMAX` ([#4555])
- sync: add `watch::Sender::send_modify` method ([#4310])
- sync: add `broadcast::Receiver::len` method ([#4542])
- sync: add `watch::Receiver::same_channel` method ([#4581])
- sync: implement `Clone` for `RecvError` types ([#4560])

### Changed

- update `nix` to 0.24, limit features ([#4631])
- update `mio` to 0.8.1 ([#4582])
- macros: rename `tokio::select!`'s internal `util` module ([#4543])
- runtime: use `Vec::with_capacity` when building runtime ([#4553])

### Documented

- improve docs for `tokio_unstable` ([#4524])
- runtime: include more documentation for thread_pool/worker ([#4511])
- runtime: update `Handle::current`'s docs to mention `EnterGuard` ([#4567])
- time: clarify platform specific timer resolution ([#4474])
- signal: document that `Signal::recv` is cancel-safe ([#4634])
- sync: `UnboundedReceiver` close docs ([#4548])

### Unstable

The following changes only apply when building with `--cfg tokio_unstable`:

- task: add `task::Id` type ([#4630])
- task: add `AbortHandle` type for cancelling tasks in a `JoinSet` ([#4530],
  [#4640])
- task: fix missing `doc(cfg(...))` attributes for `JoinSet` ([#4531])
- task: fix broken link in `AbortHandle` RustDoc ([#4545])
- metrics: add initial IO driver metrics ([#4507])

[#4616]: #4616
[#4519]: #4519
[#4582]: #4582
[#4485]: #4485
[#4613]: #4613
[#4611]: #4611
[#4626]: #4626
[#4540]: #4540
[#4555]: #4555
[#4310]: #4310
[#4542]: #4542
[#4581]: #4581
[#4560]: #4560
[#4631]: #4631
[#4582]: #4582
[#4543]: #4543
[#4553]: #4553
[#4524]: #4524
[#4511]: #4511
[#4567]: #4567
[#4474]: #4474
[#4634]: #4634
[#4548]: #4548
[#4630]: #4630
[#4530]: #4530
[#4640]: #4640
[#4531]: #4531
[#4545]: #4545
[#4507]: #4507

Signed-off-by: Eliza Weisman <eliza@buoyant.io>
crapStone pushed a commit to Calciumdibromid/CaBr2 that referenced this pull request May 1, 2022
This PR contains the following updates:

| Package | Type | Update | Change |
|---|---|---|---|
| [tokio](https://tokio.rs) ([source](https://github.com/tokio-rs/tokio)) | dependencies | minor | `1.17.0` -> `1.18.0` |
| [tokio](https://tokio.rs) ([source](https://github.com/tokio-rs/tokio)) | dev-dependencies | minor | `1.17.0` -> `1.18.0` |

---

### Release Notes

<details>
<summary>tokio-rs/tokio</summary>

### [`v1.18.0`](https://github.com/tokio-rs/tokio/releases/tokio-1.18.0)

[Compare Source](tokio-rs/tokio@tokio-1.17.0...tokio-1.18.0)

##### 1.18.0 (April 27, 2022)

This release adds a number of new APIs in `tokio::net`, `tokio::signal`, and
`tokio::sync`. In addition, it adds new unstable APIs to `tokio::task` (`Id`s
for uniquely identifying a task, and `AbortHandle` for remotely cancelling a
task), as well as a number of bugfixes.

##### Fixed

-   blocking: add missing `#[track_caller]` for `spawn_blocking` ([#&#8203;4616](tokio-rs/tokio#4616))
-   macros: fix `select` macro to process 64 branches ([#&#8203;4519](tokio-rs/tokio#4519))
-   net: fix `try_io` methods not calling Mio's `try_io` internally ([#&#8203;4582](tokio-rs/tokio#4582))
-   runtime: recover when OS fails to spawn a new thread ([#&#8203;4485](tokio-rs/tokio#4485))

##### Added

-   macros: support setting a custom crate name for `#[tokio::main]` and
    `#[tokio::test]` ([#&#8203;4613](tokio-rs/tokio#4613))
-   net: add `UdpSocket::peer_addr` ([#&#8203;4611](tokio-rs/tokio#4611))
-   net: add `try_read_buf` method for named pipes ([#&#8203;4626](tokio-rs/tokio#4626))
-   signal: add `SignalKind` `Hash`/`Eq` impls and `c_int` conversion ([#&#8203;4540](tokio-rs/tokio#4540))
-   signal: add support for signals up to `SIGRTMAX` ([#&#8203;4555](tokio-rs/tokio#4555))
-   sync: add `watch::Sender::send_modify` method ([#&#8203;4310](tokio-rs/tokio#4310))
-   sync: add `broadcast::Receiver::len` method ([#&#8203;4542](tokio-rs/tokio#4542))
-   sync: add `watch::Receiver::same_channel` method ([#&#8203;4581](tokio-rs/tokio#4581))
-   sync: implement `Clone` for `RecvError` types ([#&#8203;4560](tokio-rs/tokio#4560))

##### Changed

-   update `mio` to 0.8.1 ([#&#8203;4582](tokio-rs/tokio#4582))
-   macros: rename `tokio::select!`'s internal `util` module ([#&#8203;4543](tokio-rs/tokio#4543))
-   runtime: use `Vec::with_capacity` when building runtime ([#&#8203;4553](tokio-rs/tokio#4553))

##### Documented

-   improve docs for `tokio_unstable` ([#&#8203;4524](tokio-rs/tokio#4524))
-   runtime: include more documentation for thread_pool/worker ([#&#8203;4511](tokio-rs/tokio#4511))
-   runtime: update `Handle::current`'s docs to mention `EnterGuard` ([#&#8203;4567](tokio-rs/tokio#4567))
-   time: clarify platform specific timer resolution ([#&#8203;4474](tokio-rs/tokio#4474))
-   signal: document that `Signal::recv` is cancel-safe ([#&#8203;4634](tokio-rs/tokio#4634))
-   sync: `UnboundedReceiver` close docs ([#&#8203;4548](tokio-rs/tokio#4548))

##### Unstable

The following changes only apply when building with `--cfg tokio_unstable`:

-   task: add `task::Id` type ([#&#8203;4630](tokio-rs/tokio#4630))
-   task: add `AbortHandle` type for cancelling tasks in a `JoinSet` ([#&#8203;4530](tokio-rs/tokio#4530)],
    \[[#&#8203;4640](tokio-rs/tokio#4640))
-   task: fix missing `doc(cfg(...))` attributes for `JoinSet` ([#&#8203;4531](tokio-rs/tokio#4531))
-   task: fix broken link in `AbortHandle` RustDoc ([#&#8203;4545](tokio-rs/tokio#4545))
-   metrics: add initial IO driver metrics ([#&#8203;4507](tokio-rs/tokio#4507))

</details>

---

### Configuration

📅 **Schedule**: At any time (no schedule defined).

🚦 **Automerge**: Disabled by config. Please merge this manually once you are satisfied.

♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 **Ignore**: Close this PR and you won't be reminded about these updates again.

---

 - [ ] <!-- rebase-check -->If you want to rebase/retry this PR, click this checkbox.

---

This PR has been generated by [Renovate Bot](https://github.com/renovatebot/renovate).

Co-authored-by: cabr2-bot <cabr2.help@gmail.com>
Reviewed-on: https://codeberg.org/Calciumdibromid/CaBr2/pulls/1327
Reviewed-by: crapStone <crapstone@noreply.codeberg.org>
Co-authored-by: Calciumdibromid Bot <cabr2_bot@noreply.codeberg.org>
Co-committed-by: Calciumdibromid Bot <cabr2_bot@noreply.codeberg.org>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-tokio Area: The main tokio crate C-enhancement Category: A PR with an enhancement or bugfix. M-task Module: tokio/task R-loom Run loom tests on this PR
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants