Important: Please read the Qt Code of Conduct -


  • There seem to be a lot of Qt classes/functions that are not stated as reentrant in the official documentation, even though common sense suggests that they should be.

    For example, the class QColor is not reentrant according to the documentation. But why shouldn't it be? It's just a basic RGB container - what sort of static/global data could it possibly use?

    Is this a mistake in the documentation, or is there a reason that QColor (and such) are not reentrant?

    Each such non-reentrant class makes me add a lot of mutex related code to my library (and I'll have to tell the users of my library to use my mutex if they use those non-reentrant classes too…). I'm actually considering implementing my own "QColor" class which I'll know for sure to be reentrant, and it's a shame :(


  • Moderators

    Take a look into the source code and try to determine yourself. A cruel tip, I know and apologise, but it's one that will certainly work :)

    I suppose (== it's a guess) that info about classes being reentrant was added to qdoc3 on some stage of Qt development, and not all classes' documentation was updated.

  • Thanks sierdzio!

    I'll consider having a look at Qt's code (my problem with this approach is that if the Qt team is not committed to maintain the Reentrancy - it could change in future versions of Qt without me noticing it...).


  • The easiest way is - if you find a class that is / should be reentrant or thread-safe, but isn't marked as such - file a "bugreport": This way the community will benefit from a up-to-date documentation and you will benefit from "nailed down" developers when it comes to reentrancy or thread-safety ;)

  • good idea!

Log in to reply