Discussion

Since logging is asynchronous, adding and removing loggers is also asynchronous. In other words, the loggers are added and removed at appropriate times with regards to log messages.

• Loggers will not receive log messages that were executed prior to when they were added.
• Loggers will not receive log messages that were executed after they were removed.

These methods are executed in the logging thread/queue. This is the same thread/queue that will execute every logMessage: invocation. Loggers may use these methods for thread synchronization or other setup/teardown tasks.

Discussion

Some loggers may buffer IO for optimization purposes. For example, a database logger may only save occasionaly as the disk IO is slow. In such loggers, this method should be implemented to flush any pending IO.

This allows invocations of DDLog’s flushLog method to be propogated to loggers that need it.

Note that DDLog’s flushLog method is invoked automatically when the application quits, and it may be also invoked manually by the developer prior to application crashes, or other such reasons.

Discussion

Formatters may optionally be added to any logger.

If no formatter is set, the logger simply logs the message as it is given in logMessage, or it may use its own built in formatting style.

Discussion

If the logger implementation does not choose to provide its own queue, one will automatically be created for it. The created queue will receive its name from this method. This may be helpful for debugging or profiling reasons.

Discussion

Each logger is executed concurrently with respect to the other loggers. Thus, a dedicated dispatch queue is used for each logger. Logger implementations may optionally choose to provide their own dispatch queue.