Overriding QThread.run and calling the default implementation

[Maurizio Berti]

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 [1]
> started by QXcbWindow::create() (why? did not dig the details)
> * Main Python thread
>

That's interesting.
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
based system?
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.

Maurizio
-- 
È difficile avere una convinzione precisa quando si parla delle ragioni del
cuore. - "Sostiene Pereira", Antonio Tabucchi
http://www.jidesk.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.riverbankcomputing.com/pipermail/pyqt/attachments/20210707/0dc496d1/attachment.htm>