meta: Task Builder stabilization

[seanmonstar]

This is to track the currently unstable tokio::task::Builder API. To use it, you must pass --cfg tokio_unstable to rustc.

RFC: https://hackmd.io/Vm0UXvrNTg6HleGlD8C8sg
PR: #3881

Roadmap

• Include code from PR in a crates.io release
• Resolve open questions

Open questions

• How do we allow adding more context to the spawned task's tracing span?
  • If tracing is at 1.0, we could allow passing Builder::span directly.
  • To hide tracing, we could use some imaginary Builder::tag(name, value) that uses Span::record internally.
  • Or we could maybe make use of valuable

[dan-da]

I might be missing something, but I don't see yet how to access the name after a task is spawned with tokio::task::Builder.

When using std::thread::Builder, one can access the name via join_handle.thread().name(), but I don't see any equivalent in tokio's JoinHandle.

use case: This would be useful for me in order to log task name when acquiring a lock, for example.

[Darksonn]

Currently, the name is only accessible via the tracing traces that Tokio emits when you enable the unstable tracing feature.

[dan-da]

Currently, the name is only accessible via the tracing traces that Tokio emits when you enable the unstable tracing feature.

yes, the name is dropped here and I find that unfortunate. And even if tracing feature is enabled, the name is still not available via API.

I don't see why Builder and name should be gated behind tracing feature at all, when the concept of a named task seems generally usefully, not only for tracing. And again, it would be symmetric with functionality already offered in (stable) std::thread.

The alternative for an app wanting to keep track of named tasks is to do it themselves at each call to spawn(), eg with a struct that contains a name and a JoinHandle. This is a viable workaround, but is much less convenient eg to access within the spawned thread, and if I were moving code that already uses std::thread::Builder to tokio tasks, it would be burdensome.

Maybe this should be opened as a new issue? Anyway it seems (to me) like something that should be addressed before the Builder feature is stabilized.

[Darksonn]

The reason it's gated behind the tracing feature is that the feature was added for that specific purpose.

Still, I agree that it would be reasonable to expand this and stabilize it for other use-cases.