Skip to content

Conversation

@davidhewitt
Copy link

Motivation

Fixes #3223

Solution

From my understanding, it's sufficient for Registry::exit just to call self.try_close() and do local bookkeeping:

  • The attempt to use the thread dispatcher leads directly to the issues observed in tracing & tracing-subscriber have a design defect I believe #3223, and
  • I don't think it's correct to call try_close on the whole Layer stack at this point anyway, a span being exited is not yet ready to close. All that is needed is to decrement the reference count within the current registry.

I've added a test which spawns a thread and enters (and exits, and drops) a span created on a dispatcher not registered to that thread.

Before this patch, the test fails with the span never being closed (because there is no thread dispatcher when the span is exited, and so a reference is leaked in Registry::exit).

With this patch, the bookkeeping demonstrated in the test seems correct to me.

@davidhewitt
Copy link
Author

Note that changing Registry::exit to just call self.try_close() is also presumably a performance gain, because there is no need to dispatch through TLS on each span exit.

@vlovich
Copy link

vlovich commented Aug 1, 2025

FWIW I can also confirm this fixes the issue I've seen in real-world situations so this seems like a very simple fix that also improves performance. Great job!

@kevinji
Copy link

kevinji commented Sep 9, 2025

@jplatte are you able to review this change?

@jplatte
Copy link
Member

jplatte commented Sep 9, 2025

Hey, I'm sorry but I don't actually have a good understanding of tracing internals at all. I've just been reviewing and merging PRs that do not need much knowledge of the internals. I'm afraid this will have to wait for @hds.

@hds
Copy link
Contributor

hds commented Nov 19, 2025

Hey everyone. Just to let you know that I'm looking at this PR now. Hopefully get through it in the next couple of days.

@hds hds self-assigned this Nov 19, 2025
@hds hds added kind/bug Something isn't working crate/subscriber Related to the `tracing-subscriber` crate labels Nov 19, 2025
Copy link
Contributor

@hds hds left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you very much for your PR! I think it makes sense, I a couple of comments on the test.

Comment on lines 24 to 28
new_count: Arc<AtomicUsize>,
clone_count: Arc<AtomicUsize>,
enter_count: Arc<AtomicUsize>,
exit_count: Arc<AtomicUsize>,
close_count: Arc<AtomicUsize>,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To reduce the code in the test a bit, I think we could put all the atomics into a single struct and put that in an Arc. Then the counts could be cloned into the subscriber and the layer and compared that way.

This is really with a mind to reducing the number of lines we have in this test so that it's easier to understand.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I pushed c2f9f94 which had a go at this - I replaced the atomics with a struct behind a mutex, seems to have reduced the visual noise a bit. Let me know what you think.

@davidhewitt
Copy link
Author

Thanks will try to get feedback addressed later today 👍

@davidhewitt davidhewitt requested a review from hds November 20, 2025 21:21
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

crate/subscriber Related to the `tracing-subscriber` crate kind/bug Something isn't working

Projects

None yet

Development

Successfully merging this pull request may close these issues.

tracing & tracing-subscriber have a design defect I believe

5 participants