Repository navigation
Support reparsing filters at runtime #113
Description
Activity
I took a jab at adding support for this and have come up with two prototypes:
- Non breaking change: Added an RwLock around the filter field of the Logger struct. This approach is simple but there is a
readpenalty when accessing the filter field anytime something is logged. Code for this approach here - Breaking change: Used generics to create a logger that can change filters at runtime or forgo the ability to change at runtime to avoid the
readpenalty and remain static (basically how it is now). Code for this approach here
For both prototypes, when the logger is built you can get an instance of a new struct called
DynamicLogLevel. It has acheck_filter_configmethod that when called, checks a config file and updates the filter if the levels have changed.
The contents of this config file should follow the same syntax used for theRUST_LOGenv var.My goal is to start the conversation and possibly see if there are better ways to add support for this.
Reacted by François Bernier, Philippe Weier, Ethan Lynn, Lucia Camacho and Kun Lai- Non breaking change: Added an RwLock around the filter field of the Logger struct. This approach is simple but there is a
+1 to "this would be nice"
Reacted by Robert Jacobson and Nikita SivukhinThis suggestion doesn't feel like the "right" solution, especially if you're doing anything beyond logging to a console, but an alternative might be to have different configurations in different
Builders, and when you want to change the active configuration you just call on the appropriateBuilderto install a new logger. IfBuilderwas clonable, say, it'd be easier to incrementally modify configurations.I'm thinking about a debugger interface I'm working on in which the user can dynamically enable/disable log messages from a debug console. The actual logging features I need are dead simple—except that I want to dynamically change filtering.
Originally raised in #103