Implementing Thread Safe logging in my Qt Application
-
I want to add some logging mechanism to my application.
I am uncertain regarding the implementation though, and would really appreciate the consult of the forum members.So, I thought it will be best to first define to myself what capabilities do I want the logger to have.
It should be/have:
- Thread safe
- Multiple levels of logging
- Completely removable by a compilation flag
- Flexible - in the sense that I could easily change it (both in app launching - using console args and in compilation - using compilation flags) such that it will be able to log to any stream I'll choose (stdout/stderr/stream)
- As fast as it can be - as I don't want any hangs in the rendering of the App's GUI over this logger
- And of course - like any other thing - as loosely coupled as possible from the agents that use it (I may want to use it in a second project I want to implement)
Do you think it is possible to implement Logger that will satisfy all the above?
So this is what I have in mind:
In order to avoid locking mechanism altogether (good for bullet 5 above), the Logger will live on its own thread - and that thread will be the only thread that accesses the streams (sdtout/stderr/file), and will implement three slots for the three levels of logging (satisfies 2).
These slots will be invoked by the emission of signals, and this - together with the fact that Logger runs on its own thread - will guarantee Thread Safety (satisfies 1).
I think I can make bullet 4 work with default values for constructors and function overloading and/or compilation macros.My problem is with 6:
Every class that wants to Log something, must:- declare the appropriate signals
- connect these signals to the Logger's slots
This is impossible. I have a lot ofQWidget
's used in my app, and I cannot go and add this for everyone.
Your thoughts? Any advises? Do you see problems with the above approach?
Thanks.
-
Hi,
What about Qt's Logging Categories ?
You can combine that with qInstallMessageHandler to queue all your messages to your dedicated thread. -
@Absurd said in Implementing Thread Safe logging in my Qt Application:
Sorry... I forgot to mention; I am using Qt4. The above is only available since Qt5.2.
Any specific reason to use an EOL product version for new development?
-
When I would be your server admin I would not allow you to add a new application with a library which last was updated more than 4 years ago... but if you want to develop with such an old library you have to do such work on your own...
Otherwise I would have suggested to use log4qt from here -
@Absurd said in Implementing Thread Safe logging in my Qt Application:
I want my app to run without any additional installations.
You should rethink that, as Qt 4.8.7 was released 3 years ago and is the last patch release of the Qt 4.8 minor release, which itself was released over 8 years ago. You should either upgrade your server(s), or build Qt 5 yourself and use it for new development. Otherwise your approach (in the OP) appears sound.
-
@Christian-Ehrlicher
We have few more tools that are implemented with qt4 (for historic reasons, I believe).
What harm could that do? (developing with an old library)Thanks, I'll give logqt4 a try...
-
Security-wise it's a nightmare to use a library which is not up-to-date.
And log4qt only works with Qt5(.9)and above -
@Christian-Ehrlicher we use these machines for internal debug only (so are our tools)...
-
@Absurd as you have to deploy your app to the server anyway, why not deploy Qt 5 together with them?
All existing apps stay unchanged, but the new ones start using their own libraries.
Qt Creator does it like this, for example.
-
@aha_1980 to be honest, I'd prefer working with qt5, and I also tried to install it on one of our machines before starting the project, but I ran into so many problems and it was so complicated so I gave up.
Now it's too late anyway, because I wrote so much code in qt4... (unless qt5 is completely backward compatible with qt4)
-
Now it's too late anyway, because I wrote so much code in qt4...
For sure not ;)
(unless qt5 is completely backward compatible with qt4)
Not completely, but in many ways. I've a lot of tools compatible with both versions. That needs a few
#ifdef
, but that's it.I'd recommend doing the upgrade incrementally, because Qt 6 will appear in 2..3 years and Qt 5 will be similar to what Qt 4 is now.