rt: add runtime Id #5864
rt: add runtime Id #5864
Conversation
There are a number of cases in which being able to identify a runtime is useful. When instrumenting an application, this is particularly true. For example, we would like to be able to add traces for runtimes so that tasks can be differentiated (#5792). It would also allow a way to differentiate runtimes which are have their tasks dumped. Outside of instrumentation, it may be useful to check whether 2 runtime handles are pointing to the same runtime. This change adds an opaque `runtime::Id` struct which serves this purpose, initially behind the `tokio_unstable` cfg flag. It follows the same pattern as the `task::Id` struct. The Id can be compared for equality with another `runtime::Id` and implements `Debug` and `Display` so that it can be output as well. Internally the Id is a `u64`, but that is an implementation detail. There is a degree of code duplication, but that is necessary to ensure that the Ids are not used to compare against one another. The Id is added within the scope of working towards closing #5545.
|
The runtime id should also place in the runtime::context thread local? |
There was a problem hiding this comment.
Whether merge all taskid/threadid/runtimeid as one type id?
There was a problem hiding this comment.
Keeping a separate type because we don't want users to be able to compare (for example) a task ID to a runtime ID. Also, the runtime::Id implementation is now pretty different as we're using the value from the (Local)OwnedTasks ID.
|
We already have what is effectively a runtime id in the |
|
@Darksonn What do you think about exposing the ID from the My use case is that I would like to be able to observe the behavior of a runtime on |
|
I don't mind exposing the In fact, spawned tasks already store the id of their |
Instead of generating our own ID, use the one that has already been implemented for the owned tasks structs. The u64 value is then returned as a `runtime::Id` to keep the implementation details hidden.
|
Waiting to merge #5876, then we'll update this one. |
Darksonn
added
A-tokio
Motivation
There are a number of cases in which being able to identify a runtime is
useful.
When instrumenting an application, this is particularly true. For
example, we would like to be able to add traces for runtimes so that
tasks can be differentiated (#5792). It would also allow a way to
differentiate runtimes which are have their tasks dumped.
Outside of instrumentation, it may be useful to check whether 2 runtime
handles are pointing to the same runtime.
Solution
This change adds an opaque
runtime::Idstruct which serves thispurpose, initially behind the
tokio_unstablecfg flag.The inner value of the ID is taken from the
OwnedTasksorLocalOwnedTasksstruct which every runtime and local set alreadyhas. This will mean that any use of the ID will align with the task
dump feature.
The Id is added within the scope of working towards closing #5545.