Ranter
Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
Comments
-
Original sounds very effcient... why change? /s
Also - logging libraries exists. -
@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. -
@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. -
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.
Related Rants
-
xjose97x19Just saw a variable in C named like this: long time_ago; //in a galaxy far away I laughed no stop.
-
Unskipp24So this happened last night... Gf: my favorite bra is not fitting me anymore Me: get a new one ? Gf: but it ...
-
sam966911Hats off to this lady .... I would have just flipped the machine
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.
rant
wk368
c++