Important: Please read the Qt Code of Conduct -

QIODevice on other thread than MAIN

  • Hy,

    in ICS i found some quite old (year 2003 i think) whitepaper about QT application performance. There was interesting recommendation about threading and classes that derive from QIODevice:

    bq. Never create QWidget or QIODevice subclasses from any thread other than the main

    Is this true for current versions of QT? Target OS'es are Linux and Windows. Thanks indeed

  • QWidget derived classes should be only used in one single thread (does not necessarily have to be the main thread). I'm not sure why QIODevices should not be used in threads. QFile is a QIODevice and I'm pretty sure someone has to do some threaded file handling somewhere.

    Did the whitepaper state why QIODevices should not be used outside the main thread?

  • could you post the whitepaper for us? might be intressting for some more people.

  • Link to whitepapers at ICS:

    "ICS Whitepapers":

    The whitepaper I mention here is named: Turbocharging Qt Applications
    You mus register at ICS in order to download it. Registration is easy an free ...

    Thats what is said about Windows and QT threading in this whitepaper:

    bq. Windows has its problems as well. While the underlying GUI libraries are in theory
    thread-safe (in practice, the so-called “consumer Windows versions” Windows 95/98/ME
    have stability issues with multithreading in GUI programs), memory management
    requires that you do not create any widgets or sockets (or anything else that handles
    operating system events) from any other thread than the main thread.

    I suspect that this applies to old Windows versions (9x). I myself use QUdpSocket at other threads than MAIN in WIN XP ... but I'd like to have some confirmation that it is really safe from someone who knows WIN32 api better than me:) I am trying to search for answer in internet but no results yet. Just found in many places that win socks are thread safe.

Log in to reply