8

Existing code:
Logger class would block the caller, lock a mutex, call CreateFile(), write a single line to the file, unlock the mutex and return.

Improvement:
Added two logging queues and created a thread that will periodically lock one queue and write it to the disk, around 500 entries at a time, while new entries are being inserted into the other queue. Kinda like a bed pan or urine bottle. While emptying one bottle, the logs go into the other one. Added fatal exception handlers so that the log queues are dumped when the application is crashing. When the exception handler is triggered, logging method does not return so that the application STOPS working to make sure there are no "not logged" activities.

Comments
  • 3
    Original sounds very effcient... why change? /s

    Also - logging libraries exists.
  • 2
    @magicMirror

    The codebase is very old. Probably older than some users here. Certain header files bear (c) 1997. Couldn't find a library in the amount of time we had been given that would fulfill the requirements.
  • 1
    Log4j existed back then...
  • 3
    @magicMirror Yeah... Note the "J" in Log4J and my username ;)

    The code-base is C++, not some blasphemous aberration named after a type of coffee that allowed everyone to create software without worrying about freeing memory they are using, or performance.
  • 0
    These kind of problems are already solved. Best using reactive streaming libraries.
  • 0
    Do you really need more than one thread per process?
  • 1
    This sounds like what most of the logging libraries do behind the scenes.

    Libraries might exist, but given the simplicity of the task it's debatable.

    Locking per entry definitely sucks, cause then you have a happy mutex spawning machine unnecessarily stopping things... Not using mutex could be dangerous given that messages should be added in synchronous order, otherwise it might end funny (asynchronous logging in non-ordered fashion is really funny... Not.).

    So the overflow buffer makes sense, to fulfill both needs: ordered logging and writing in bulk, thus reducing the number of mutexes spawned and preventing locking per entry.

    Good job.
Add Comment