Why is new_span(&self) and not &mut self?

[singpolyma-shopify]

Feature Request

Motivation

It seems like the whole purpose of the new_span API is to store data about the new span and associate it with an id. The data will need to be stored in most cases since the event/enter/etc APIs only pass an id. However, new_span does not take self mutably, so one must resort to hacks in order to store the data anywhere.

Proposal

new_span should take &mut self

Alternatives

mut self? Probably not needed.

[hawkw]

A subscriber may be shared across multiple threads, so it's not possible to have any methods on the Subscriber trait that take &mut self. Instead, subscribers that store data about spans must use a storage method that allows writes across threads, either via locking the store, by sending writes through a channel to a dedicated reader task, or (ideally) by using a concurrent data structure.

There's an issue (#157) for providing a fast concurrent store for span data as a library for subscriber implementors to depend on — there are some optimizations that we can likely make that are specific to the tracing use-case. In the meantime, the concache and chashmap crates are likely to be good options, and evmap may be worth a look in some use-cases as well.

[singpolyma-shopify]

So the subscriber itself isn't protected or on the other side of an mpsc or similar?

I guess the idea is this can allow different consumers to get some performance gains if they don't need as much protection?

[hawkw]

So the subscriber itself isn't protected or on the other side of an mpsc or similar?

I guess the idea is this can allow different consumers to get some performance gains if they don't need as much protection?

Yeah, that's right! What data a subscriber stores, and how it stores that data, could vary wildly based on the behaviour it implements: some might not store any data at all, and just write it all to some form of I/O immediately, for example, and others might only store data for a subset of spans or events. Therefore, we determined that this should be left up to the subscriber implementation in tracing-core, to not inflict the overhead of channels or locking on subscriber implementations which don't need it.

The plan is that the tracing-subscriber crate will provide utilities for subscriber authors that implement some of the common strategies, so that they don't have to be rewritten by every implementation. This crate isn't quite done yet, although it's being actively worked on.

[singpolyma-shopify]

Interestingly, I cannot protect my Subscriber behind an mpsc because of the requirement for new_span to return an Id and not a Future<Item=Id>

[singpolyma-shopify]

I think probably it would be very useful if the Store from https://github.com/tokio-rs/tracing/blob/master/tracing-fmt/src/span.rs moved into tracing-subscriber or similar for re-use