@witty-crayon-22786 @dry-policeman-7927 @red-balloon-89377 @fancy-motherboard-24956 @average-vr-56795 @hundreds-breakfast-49010 would it be at all useful if i looked at trying to port pants to the

tracing

crate (https://github.com/tokio-rs/tracing) to make it easier to define v2 workunit spans in rust? we could even spawn a zipkin span for every single method call if we wanted to, as well as every hop across the FFI boundary. the github page has a few examples describing why we might want to do this. the

tracing

crate also decouples creating spans and logging those spans, where logging is delegated too a

tracing::Subscriber

. the two parts this needs are: (1) to port to the

tracing

crate, which i've started (a while ago) here: https://github.com/pantsbuild/pants/pull/7395 (2) to implement a

tracing::Subscriber

for zipkin, which i've mostly done here: https://github.com/cosmicexplorer/learning-progress-bar/blob/master/zipkin/src/lib.rs, and can upstream in a separate PR

It's potentially useful, yea, although maybe not the highest priority. Given that Toolchain is actively consuming the spans that are currently generated, you'd want to make sure that they'll have time to sanity check the changes against their consumers

def not high priority

I suppose that if optimization is a high priority, then having more options for profiling is handy.

yes i think so that would be my primary motivation to do it

Yea. Could expose rust tracing methods to python, but it's a bit orthogonal.

100%

@aloof-angle-91616 I spent a couple of hours last week trying to start using

tracing

to replace the current `WorkUnit`/`WorkUnitStore` abstraction and didn't get anywhere, so I decided it might be a better use of time to just continue using those abstractions

so. stopping a bit short of actually migrating to the tracing crate, how would folks feel about a patch to make the workunit_store thread/task local? we currently manually pass it everywhere, and similar to logging and the trace ids themselves, that's pretty clearly not necessary

i would love to review that or break off a part of that if it would help

but would be almost entirely "remove the parameter"

not me!

ok, i now think that we should in fact move to

tracing

. i think that this patch will be a good step in that direction, but the thread/task local management is too wheel-reinventy.

@witty-crayon-22786 not right now, so I'd be more than happy to review such a patch now beofre I do make any changes