Disconnects from the log producer as soon as possible, possibly leaving messages behind in the log buffer. Once disconnected, the log listener will terminate asynchronously and cannot be reused. Use waitForCompletion to block your thread until the termination is complete.
Waits for the listener to finish its pending work and terminate. You should call disconnect first to make it start to exit.
The arsd.core logger works differently than many in that it works as a ring buffer of objects that are consumed (or missed; buffer overruns are possible) by a different thread instead of strings written to some file.
A library (or an application) defines a log source. They write to this source.
Applications then define log listeners, zero or more, which reads from various sources and does something with them.
Log calls, in this sense, are quite similar to asynchronous events that can be subscribed to by event handlers. The difference is events are generally not dropped - they might coalesce but are usually not just plain dropped in a buffer overrun - whereas logs can be. If the log consumer can't keep up, the details are just lost. The log producer will not wait for the consumer to catch up.
An application can also set a default subscriber which applies to all log objects throughout.
All log message objects must be capable of being converted to strings and to json.
Ad-hoc messages can be done with interpolated sequences.
Messages automatically get a timestamp. They can also have file/line and maybe even a call stack.
auto logger = new shared LoggerOf!GenericEmbeddableInterpolatedSequence; mylogger.info(i"$this heartbeat");
Added May 27, 2024
Not actually implemented until February 6, 2025, when it changed from mixin template to class.
DO NOT USE THIS YET IT IS NOT FUNCTIONAL NOR STABLE