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.
