tracing: instrument task wakers #3836
Conversation
|
|
||
| cfg_trace! { | ||
| mod trace; | ||
| pub(crate) use trace::InstrumentedFuture as Future; |
There was a problem hiding this comment.
This rename was mostly for convenience in all the other modules. But it could be that people find it too confusing, in which case I'll ditch the rename and just make the name change in all the other places.
There was a problem hiding this comment.
Does this change the public API of spawn methods to use a different trait, or is it only internal? I can't really tell.
There was a problem hiding this comment.
No it doesn't. And I checked in a playground, since the trait is pub(crate) the compiler will error if the bounds were used on a pub function.
seanmonstar
force-pushed
the
tracing-wakers
branch
from
b639684
to
1d40aee
Compare
Darksonn
added
A-tokio
| if let Some(id) = $harness.id() { | ||
| tracing::trace!( | ||
| target: "tokio::task", | ||
| op = %$op, |
There was a problem hiding this comment.
i can see why this is a potential use-case for custom event names...we should definitely consider adding the option to override event names upstream, so that we can use custom names here rather than a field value...but, again, this is fine for now.
| cfg_trace! { | ||
| macro_rules! trace { | ||
| ($harness:expr, $op:expr) => { | ||
| if let Some(id) = $harness.id() { |
There was a problem hiding this comment.
it looks like the intention here is to avoid emitting the event if the task is not being tracked? i wonder if we actually want to do this inside of the tracing event macro, to handle cases where the event is disabled by one of tracing's filtering fast paths. e.g., if the user compiles tracing with one of the "static_max_level_xxx" feature flags, the event macro will be completely empty and won't compile to any code, but we'll still dereference the trailer and check if it has a task ID.
this is probably an unnecessary microoptimzation, though, and we could do it later --- moving it inside the macro will be much easier when tokio-rs/tracing#1393 is published, anyway.
There was a problem hiding this comment.
Yea, I'd really want to be to check tracing if the event would be emitted, and check if the ID is Some, in the same if statement. I don't want to emit an event if we're not tracking the task either.
Co-authored-by: Eliza Weisman <eliza@buoyant.io>
Motivation
In support of tokio-rs/console#37, we want to understand when a specific task's waker has been interacted with, such as when it is awoken, or if it's forgotten (not cloned), etc.
Solution
When the
tracingfeature is enabled, a super trait ofFuture(InstrumentedFuture) is implemented forInstrumented<F>that allows grabbing the task's ID (well, its span ID), and stores that in the raw task trailer. The waker vtable then emits events and includes that ID.