std.experimental.logger: practical observations

[Cliff via Digitalmars-d]

On Monday, 15 September 2014 at 18:24:07 UTC, Marco Leise wrote:
> Ah, so you avoid recursion issues by separating the calls to
> error() et altera from the actual process of writing to disk
> or sending via the network.
>
> Behind error() there would be a fixed implementation
> controlled by the author of the logging library that just
> appends the payloads to a list.
> Another thread would pick items from that list and push them
> into our Logger classes where we can happily use the logging
> functionalities ourselves, because they would just get
> appended to the list and wait for their time instead of
> causing an immediate recursive call.
>
> So basically your idea is message passing between the
> application and a physical (probably low priority) logging
> thread. This should also satisfy those who don't want to wait
> for the logging calls to finish while serving web requests.
> How do such systems handle a full inbox? In Phobos we have
> http://dlang.org/phobos/std_concurrency.html#.OnCrowding

In MSBuild (where we used a custom but extensible logging system)
we had this exact issue with some of our larger customers who
were logging to remote databases.  Our solution in that case was
to block the caller and force a flush down to a certain backlog
level (we had a limit and hysteresis).  This is not unlike
garbage collector behavior.  In fact, you almost certainly want
to have a configuration of this sort so that users of your
library can help ensure that the logging subsystem does not
starve the rest of the application of memory.

Another alternative (for completeness) is to drop the messages,
but this is almost invariably NOT desirable.