Part (2/2): Active Objects for Asynchronous Logging.

Contra-auguste Active Object

TL;DR It's just an slightly better (imho) implementation of Sutter's Dr. Dobbs 2010 articles [1][2]

As per Lavender & Schmidt's article[3] Sutter's implementation is a further refinement of the integrated scheduler variant of their original pattern removing, as it does, altogether the proxy and scheduler relying on direct message passing between client and scheduler. 

Indeed Sutter's scheduler (his Active class) contains the message queue as a private composition -which is too much integration. Too much because it forces the client to be aware of the scheduler which as an unnecessary, and avoidable, level of dependancy that binds the scheduler to the client.

The client need only be aware of the tail of the activation queue and, hence, the has-a-relationship with the message queue can be broken out of the scheduler for a more naturally component orientated approach that facilitates scheduler fungibility. Further, the scheduler need only be aware of the head of the activation queue.

All of which leads to the message request scheduler:

The usage is as below and demonstrates that anything can be passed as message request function but an anonymous inner function expressed as a lambda function is an intuitive approach:

All of which makes for a very simple asynchronous stream serializor:

The usage of async_stream within the logger is straightforward:

This little sojourn into utilising C++11 language features and idioms for a general purpose logger with an asynchronous stream serializor has (hopefully) been interesting, but does it bring us any nearer to an actual libfbp?

Perhaps the next blog entry will elicudate...?

References:

[1] Prefer Using Active Objects Instead of Naked Threads

[2] Prefer Using Futures or Callbacks to Communicate Asynchronous Results

[3] Active Object - Lavender & Schmidt 2010