Support an API to extract backtrace information from taskdump

[mox692]

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: #5638

[Darksonn]

cc @jswrenn

[jswrenn]

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]

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

[arielb1]

Is there a strong reason we don't just export an API that is of the form:

pub struct TokioBacktraceFrame {
    name: Option<Vec<u8>>,
    name_demangled: Option<String>,
    addr: Option<*mut c_void>,
    filename: Option<PathBuf>,
    lineno: Option<u32>,
    colno: Option<u32>,
}

impl TokioBacktraceFrame {
    pub fn name_raw(&self) -> Option<&[u8]> { /* .. */ }
    pub fn name_demangled(&self) -> Option<&str> { /* ... */ }
    pub fn addr(&self) -> Option<*mut c_void> { /* ... */ }
    pub fn filename(&self) -> Option<&Path> { /* ... */ }
    pub fn lineno(&self) -> Option<u32> { /* ... */ }
    pub fn colno(&self) -> Option<u32> { /* ... */ }
}

impl Trace {
    pub fn dump(&self) -> Vec<Vec<TokioBacktraceFrame>>;
}

I believe that this will work with every form of taking backtraces (especially given that all fields are options). Possibly it will require some inefficiency, but we can always expose a more efficient API later.

[Darksonn]

Tokio does not and will not depend on serde.

[arielb1]

K, so without the derive(Serialize) but with exposing accessors. People will have to do another map if they want to turn it to a JSON which will have some negative performance implications, but I think this is acceptable.

[Darksonn]

We can probably expose some accessors.

[arielb1]

So are you positive for a function returning a Vec<Vec<TokioBacktraceFrame>> for a TokioBacktraceFrame that is supposed to be a plain old data type with accessors?

[Darksonn]

Yes, we can add it.