open to a PR for deinitialize?

[dunmatt]

Hello all, I was wondering if this crate would be open to a PR that adds pub fn deinitialize() -> Option<&'static Log>. The goal is that I'd like to be able to write a crate for composing loggers, but currently loggers aren't constrained to expose the loggers they generate publicly, so the only way to reliably compose them would be to have some means of pulling them out of your &'static mut LOGGER.

[sfackler]

Previous versions of the crate supported deinitialization, but we removed it as it added a nontrivial synchronization cost to every log call.

You use case seems like it would be better served by having the logger implementations expose their loggers directly anyway, right?

See also #267

[dunmatt]

It would certainly be better served by forcing the logger implementations to expose their loggers in a standard way, but that seems like a much more intrusive change since it would require a major rev. What if I can find a way to do it without the synchronization cost?

[sfackler]

There would be no change to this crate - you'd instead go to the various logger crates and ask them to expose direct constructors for their loggers.

[dunmatt]

It turns out there's a reason I italicized "forcing" above. I'm looking for a solution I can depend on, and herding all those cats doesn't strike me as one of those. Even if I got them into line once there's nothing that keeps them there.

But it sounds like the answer to my question is "no, even if there's no per-log-call sync cost, we're not open to this change".

[Dgame]

I have a similar goal because I want to change the format of the logger after I've already initialized it. This is because I want to include a transaction ID in the format as soon as I've identified it. Unfortunately, this is not possible immediately and I want to be able to log potential errors without having a transaction ID. Since I can neither change the format of the logger nor set a new one, I have no idea how to do this. Do you have a suggestion?

[sfackler]

It seems like you'd want your logger implementation to provide the ability to adjust its configuration.

[Dgame]

Seems so, but I haven't found one that can do that after the logger has been globally initialized.

[sfackler]

log4rs can do that as one example.

[Dgame]

Thanks a lot! But I'd hoped to find something simpler. Are there any criterias I can search for?

[sfackler]

Not sure.

[dbrgn]

I'm using log4rs in a crate that's consumed over FFI and am looking for a way to free the logger's memory / drop the logger.

Right now I reconfigure log4rs with a logger that's as simple as possible. But it still requires some memory. log4rs sets its own logger using log::set_boxed_logger.

There's no way to "undo" that, right?

[KodrAus]

Just coming through some triage. It's been a while since we've had any activity here. I don't think we're looking at re-introducing de-initialization support in log itself. Ideally, implementors of the Log trait would expose concrete types that consumers can use to construct and compose them. It does require work in all Log implementors, but that work has broader benefits than just de-initialization.