Using in tracing?

[QnnOkabayashi]

Hello, potentially a newbie question. You mentioned in the FAQ that this was intended for tracing Subscribers: how would you resolve the case where the buffer is full? Would this involve blocking until it can be sent? AFAIK the Subscriber API is entirely synchronous, so I assume you can't async send. I'm curious because tracing-forest currently uses a Tokio unbounded queue, and I'm curious about alternatives.

[hawkw]

My intended use case was in tracing-appender's non_blocking module, which provides a utility for performing file IO on a background thread rather than on the threads that record events. You're correct that the channel would be used either by blocking when the channel is full, or by dropping new messages when at capacity. tracing_appender::non_blocking currently provides a builder parameter to allow configuring what happens when the channel is full --- either new dropping new log lines when there isn't space in the queue, or blocking.

In general, I would strongly advise against the use of unbounded queues of log messages. This can lead to memory exhaustion when the background task or thread cannot keep up with the production of new messages. It's almost always preferable to drop messages when a channel is full, and have some mechanism for indicating to the user that this took place.