Overriding QThread.run and calling the default implementation
maurizio.berti at gmail.com
Wed Jul 7 01:03:30 BST 2021
Il giorno mar 6 lug 2021 alle ore 10:40 Giuseppe Corbelli <
corbelligiuseppe at mesdan.it> ha scritto:
> First let's note that there are a few threads running by default. I
> added a setObjectName() to the worker thread before run() so that it's
> easily spottable in GDB.
> * Worker thread is running QEventLoop::exec()
> * QDBusConnection, assume started automatically by Qt (QEventLoop::exec())
> * QXcbEventQueue (xcb_wait_for_event()) defined in the Qt XCB platform
> plugin, assume started automatically by Qt
> * 4 threads python:disk$0 to python:disk$4 waiting on a futex 
> started by QXcbWindow::create() (why? did not dig the details)
> * Main Python thread
So, actually, there's also a QDBus thread that's started with *any* new
QApplication? Or is it just for any UI based application started on a DBus
Be aware, the above questions might be nonsensical: unfortunately my
knowledge of deep-level programming is close to none, so I might be saying
a "corbelleria" ;-)
Would you care to provide the steps you did to get the above? I do have
gdb, but I only used it a few times in the past and only under guidance.
That said, I want to thank you all for your inputs: even if we can already
assume that this is not a bug any more and, in normal conditions, one
doesn't usually call the default run() implementation (since calling exec()
solves the issue in any case), it has been a really useful and insightful
thread so far.
È difficile avere una convinzione precisa quando si parla delle ragioni del
cuore. - "Sostiene Pereira", Antonio Tabucchi
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the PyQt