tokio-rs / tokio

A runtime for writing reliable asynchronous applications with Rust. Provides I/O, networking, scheduling, timers, ...
https://tokio.rs
MIT License
26.41k stars 2.43k forks source link

Support an API to extract backtrace information from taskdump #6309

Open mox692 opened 7 months ago

mox692 commented 7 months ago

Is your feature request related to a problem? Please describe. Currently, the only supported output for taskdump is logging, as shown in the examples here. However, I would like to add a public API that can extract this backtrace information. By adding such an API, it will become possible to handle taskdump data programmatically, making it useful for various purposes.

Describe the solution you'd like I would like to add a public API something like this:

struct Symbol {
  // one call stack info
}

pub struct TraceTree {
  symbol: Symbol,
  children: Vec<TraceTree>
}

impl Task {
  pub fn trace_tree(&self) -> TraceTree { ... }
}

async fn run {
  let handle = tokio::runtime::Handle::current();
  let dump = handle.dump().await;
  for task in dump.tasks().iter() {
    // get a trace tree per one tokio task.
    let root: TraceTree = task.trace_tree();

    // some traverse operations...
  }
}

We already have an internal struct named Tree, so I believe it's not too hard to provide such an API.

Additional context related issue: https://github.com/tokio-rs/tokio/issues/5638

Darksonn commented 7 months ago

cc @jswrenn

jswrenn commented 7 months ago

It's not hard to provide an API here, but it might be hard to provide the right API. The current Tree type is an implementation detail used to aid printing task dumps. It's not currently designed to function well as a public API for traversing the tracing tree. Rust doesn't have a standard interface for tree traversal, so we'll need to decide for ourselves what interface to expose. We'll also need to ensure that this API doesn't lock us into sub-optimal representation decisions.

mox692 commented 7 months ago

Thanks for clarifying the context! Yeah, deciding on the right api seems difficult, but I believe we should eventually reach.