Runtime identifier and name #5545
Labels
Comments
hds
added
A-tokio
hds
added a commit
that referenced
this issue
Jul 13, 2023
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.
hds
added a commit
that referenced
this issue
Jul 13, 2023
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.
Merged
hds
added a commit
that referenced
this issue
Jul 13, 2023
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.
hds
added a commit
that referenced
this issue
Jul 19, 2023
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. The inner value of the ID is taken from the `OwnedTasks` or `LocalOwnedTasks` struct which every runtime and local set already has. 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.
|
Would a PR be accepted which stabilises this feature? It would be extremely useful for us. |
|
Hmm. We should definitely stabilize task ids soon, and I guess this could go with it. It doesn't seem like there is an issue for stabilizing task ids ... |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Is your feature request related to a problem? Please describe.
In certain circumstances, it would be useful for introspection of Tokio if it was possible to identify a runtime.
This would unlock new features and analyses in
tokio-console(some described in console#130, and another in console#229).I believe it would also add value to
tokio-metrics.There are two different forms of identification that would be useful:
In a sense these are two features, but to me it made more sense to present them together.
Describe the solution you'd like
Foe the identifier, an opaque struct that can produce a
Sizedvalue would be ideal for the public API.Internally a (thread-safe) counter could be used. Each new runtime is assigned the next value. A
u64will provide more values than can be used during the lifetime of a process (or ever). This aligns with the task Id currently available in unstable.The identifier would be available from the runtime
Handle.The runtime name could be optionally provided to the runtime builder.
It would then be available on the
Handle.Describe alternatives you've considered
Foe the
tokio-consoleuse-case alone, theconsole-subscribercould keep track of runtime creation and assign each an Id. However linking this back to the tasks executing on the runtime and the resources associated with the runtime would be much more complicated (maybe not possible?).If an identifier is available in the tokio API, bit no name, then the
console-subscriberortokio-consolecould apply the mapping based on user input. However unless the runtime identifier would be stable, this mapping would need to be provided on every run of the final application.Additional context
Both
tokio-console(reallyconsole-subscriber) andtokio-metricsalready require that tokio be built with thetokio_unstablecfg option set, as such it would be sense to put this feature in unstable as well, especially initially.As well as use in
tokio-consoleandtokio-metrics, a name or a way to distinguish Runtimes could be useful in other contexts.Any application which runs multiple Runtimes, or frequently creates new runtimes (from memory
reqwestdoes this for the sync API) may like to be able to distinguish between them at execution time.The text was updated successfully, but these errors were encountered: