For the speed reasons, you may want to dump logs asynchronously. It is especially useful when application threads are CPU bound while logs emitting is I/O bound. This approach allows mitigating bottlenecks from the I/O.

When writing an application user should be aware of the tradeoffs that concurrent log system can provide, in this module, we explain potential tradeoffs and describe if individual building blocks are affected or not.

1. _Unbounded memory usage_ - if there is no backpressure mechanism the user threads, threads may generate more logs that can we can store at the same amount of time. In such cases messages are accumulated in memory. It extends GC times and memory usage.
2. _Persistence requirements_ - sometimes application may want to ensure that we persisted the logs before it moved to the next statement. It is not a case with concurrent log systems in general; some we lose logs even the thread moves forward. It may happen when the application exits before dumping all logs.
3. _Non-precise logging_ - sometimes there may be anomalies when storing logs, such as logs reordering or imprecise timestamps.

In case if your application is a subject of those problems you may consider not using concurrent logging system in other cases concurrent logging may be a good default for you.

Concurrent logger consists of the following building blocks (see schema below).

1. *Logger in the application thread*. The application runs it in the main thread, and it has access to all the thread state. This logger can work in any m.
2. *Communication channel with backpressure support*. In addition to the channel, we have a converter that puts the user message to the communication channel. This converter works in the user thread. Such a logger usually works in IO, but it's possible to make it work in STM as well. At this point, the library provides only IO version, but it can be lifted to any MonadIO by the user.
3. *Logger thread*. It's a background thread that performs an actual synchronous write to the log sinks. Loggers there do not have access to the users' thread state.

   +-------------------------+                  +--------------------------------+
   |                         |                  | Logger        |   Sink-1       |
   |   Application Thread    |                  | Thread    +--->                |
   |   -----------------     |  +-----------+   |           |   +----------------+
   |                         |  |           |   +---------+ |   +----------------+
   |           +-------------+  |  channel  |   | Shared  +----->   Sink-2       |
   |           | application||  |          +----> logger  | |   |                |
   |           | logger    +----->          |   +---------+ |   +----------------+
   |           +-------------+  |           |   |           |   +----------------+
   |                         |  +-----------+   |           +--->   Sink3        |
   |                         |                  |               |                |
   |                         |                  |               +----------------+
   |                         |                  |                                |
   +-------------------------+                  +--------------------------------+

So usually user should write the logging system in the way that all 'LogAction.' that populate and filter information should live in the application logger. All loggers that do serialization and formatting should live in the shared logger.

If you need more concurrency it's possible to build multilayer systems:

  +-------------+                         +-------+
  | application |---+                 +---| sink-1|
  +-------------+   |   +---------+   |   +-------+
                    +---| logger  |---+
                        +---------+   |   +-------+
                                      +---| sink-2|
                                          +-------+

In this approach, the application concurrently writes logs to the logger, then the logger concurrently writing to all sinks.

Simple API provides a handy easy to use API that can be used directly in an application without dealing with internals. Based on users feedback, the internal implementation of the simple API may change, especially in early versions of the library. But the guarantee that we give is that no matter what implementation is, it keeps with reasonable defaults and can be applied to a generic application.

Extended API explains how asynchronous logging is working and provides basic building blocks for writing your combinators. It is the part of the public API and does not change without prior notice.

The main abstraction for the concurrent worker is BackgroundWorker. It is a wrapper of the thread, that has a communication channel to talk to and threadId.

Background worker may provide a backpressure mechanism, but does not provide notification of completeness unless it's included in the message itself.

While generic background logger is enough for the most of the usecases, sometimes you may want even more.

There are at least two cases where that may happen:

1. You need to modify logger, for example different threads wants to write to different sources. Or you want to change lgo mechanism in runtime.
2. You may want to implement some notification machinery that allows you to guarantee that your logs were written before processing further.

In order to solve those problems worker thread abstraction was introduced. This is a worker that accepts any action and performs that.

Consider following example. (Leaving resource control aside).

data M msg = M (MVar ()) msg

notificationLogger :: MonadIO m => LoggerAction m msg -> LoggerAction m (M msg)
notificationLogger logger = LogAction $ (M lock msg) ->
   (unLogger logger msg) finally (putMVar lock ())

example = do
   worker <- mkBackgroundThread defCapacity
   lock <- newEmptyMVar
   -- Log message with default logger.
   unLogger
      (runInBackgroundThread worker
      (notificationLogger $ withLogByteStringFile "/var/log/myapp/log")
      (M lock "my message")
   -- Log message with a different logger.
   unLogger
      (runInBackgroundThread worker
      (withLogByteStringFile "varlogmyapplog")
      ("another message")
   -- Block until first message is logged.
   _ <- takeMVar lock