Implement minimal (metrics-only) taskdumps.

[jswrenn]

This PR is the first in a series implementing the task dump feature proposal (#5457). This initial implementation includes only runtime metrics; e.g.:

{
  "flavor": "MultiThread",
  "metrics": {
    "num_workers": 72,
    "num_blocking_threads": 72,
    "num_idle_blocking_threads": 0,
    "remote_schedule_count": 1,
    "io_driver": {
      "fd_registered_count": 0,
      "fd_deregistered_count": 0
    }
  }
}

Implementation Details

This PR internally uses serde to provide flexible serialization of runtime internals. For testing, the schemars dev-dependency is used to generate a JSON schema against which task dumps can be validated (with jsonschema).

API

Before merging this PR, we should settle on an API for task dumps. Possibilities include:

/* this is what the PR implements at the time of creation */
impl fmt::Display for Handle {
    fn fmt(&self, f: &mut fmt::Formatter<'_>) -> fmt::Result {
        ...
    }
}

/* used like: */
println!("{}", Handle::current());

or

impl Handle {
    pub fn write_taskdump_json<W>(&self, mut writer: W) -> io::Result<()> 
    where
        W: io::Write,
    {
        ...
    }
}

/* used like: */
let handle = Handle::current();
let mut stdout = std::io::stdout().lock();
handle.write_taskdump_json(&mut stdout)?;
stdout.write_all(b"\n")?;
stdout.flush()?;

or

impl Handle {
    pub fn taskdump_json(&self) -> String {
        ...
    }
}

/* used like: */
println!("{}", Handle::current());

or something else? Suggestions welcome! My hope is we provide a streamlined API that can be used for serializing JSON task dumps to stdout or files. This streamlined API should co-exist with a possible future, more expansive API that provides options to skip traversing certain runtime structures and the option to serialize into other formats.

[hds]

I think that some of the concepts here require further discussion before continuing. Probably worth continuing on the original issue and/or on Discord before adding too much more.

[hds]

Even allowing that this would be an opt-in feature, adding serde and serde_json seems like a fairly large addition to tokio's dependencies.

[hds]

This was already brought up on the feature proposal issue (#5457), but I'll add it here too.

I feel that performing excessive work inside the Display trait violates the consistency principal (principal of least surprise). My opinion (and so it is just that) is that most users would expect adding a Handle to some println!() call to be "harmless", and I don't think serializing the state of the runtime can be classed as such.

[sfackler]

Is this a task dump API or a metrics API? IIRC tokio already has the ability to emit these metrics.

[jswrenn]

@sfackler My goal with this initial PR is to pin down the taskdump API and to touch as little of Tokio's internals as possible. Indeed, the reason this only includes metrics now is because Tokio already has an API for metrics. Once we settle on a satisfactory API for task dumps, I'll submit follow-up PRs that include incrementally increasing information about tasks.

[sfackler]

But why would we want this API to report metrics in the first place? If you just want to add the method, it may as well just return an empty JSON object or something.

[jswrenn]

My goal is to surface as much important information from Tokio's internals as is possible without introducing new runtime costs. Runtime metrics are readily (and cheaply) available already. They even might be helpful for debugging. I couldn't see a reason not to include them.

Additionally, the goal of this PR is to lay the groundwork for future PRs. There are three components to it: the public API, the serialization mechanism, and the testing approach. Returning {} would have made it difficult to develop and meaningfully validate the testing approach.

[Darksonn]

As discussed privately, the initial task dump PR will use a different implementation. I will close this. Go ahead and open a new PR when your changes are ready.