Collectives™ on Stack Overflow

Find centralized, trusted content and collaborate around the technologies you use most.

Learn more about Collectives

Teams

Q&A for work

Connect and share knowledge within a single location that is structured and easy to search.

Learn more about Teams

I have a Qt application written in PySide (Qt Python binding). This application has a GUI thread and many different QThreads that are in charge of performing some heavy lifting - some rather long tasks. As such long task sometimes gets stuck (usually because it is waiting for a server response), the application sometimes freezes.

I was therefore wondering if it is safe to call QCoreApplication.processEvents() "manually" every second or so, so that the GUI event queue is cleared (processed)? Is that a good idea at all?

That's an excellent question, and I have no good answer. I once asked on the Qt forums and they said it was because the application is not processing any events, and that's why it appears that it is frozen. Might also have something to do with the fact that there are 100+ threads running at the same time. Bo Milanovich Feb 22, 2013 at 0:45 If the main thread is in the Qt event loop, it should process messages (unless your machine is too busy, but that is not directly related to your code). wRAR Feb 22, 2013 at 0:51 Yes, it is in the event loop. But still, I have found that when calling processEvents() the application does NOT freeze - so is it safe to do so? Bo Milanovich Feb 22, 2013 at 1:00 What is your thread/cpu ratio? What would you expect to happen if ncpu threads all block waiting for I/O (this is a real question, I am not sure)? My guess would be what you are describing, the main thread never gets scheduled to clear it's event que and looks like it is frozen. tacaswell Feb 22, 2013 at 1:15

It's safe to call QCoreApplication.processEvents() whenever you like. The docs explicitly state your use case:

You can call this function occasionally when your program is busy performing a long operation (e.g. copying a file).

There is no good reason though why threads would block the event loop in the main thread, though. (Unless your system really can't keep up.) So that's worth looking into anyway.

  • Every so often the threads want to send stuff back to the main thread. So they post an event and call processEvents

  • If the code runs from the event also calls processEvents then instead of returning to the next statement, python can instead dispatch a worker thread again and that can then repeat this process.

  • The net result of this can be hundreds or thousands of nested processEvent statements which can then result in a recursion level exceeded error message.

    Moral - if you are running a multi-threaded application do NOT call processEvents in any code initiated by a thread which runs in the main thread.

    B. You need to be aware that CPython has a Global Interpreter Lock (GIL) that limits threads so that only one can run at any one time and the way that Python decides which threads to run is counter-intuitive. Running process events from a worker thread does not seem to do what it says on the can, and CPU time is not allocated to the main thread or to Python internal threads. I am still experimenting, but it seems that putting worker threads to sleep for a few miliseconds allows other threads to get a look in.

    Thanks for contributing an answer to Stack Overflow!

    • Please be sure to answer the question . Provide details and share your research!

    But avoid

    • Asking for help, clarification, or responding to other answers.
    • Making statements based on opinion; back them up with references or personal experience.

    To learn more, see our tips on writing great answers .