[Development] Stepping down as QtDBus maintainer
thiago.macieira at intel.com
Thu May 18 18:18:02 CEST 2017
On Thursday, 18 May 2017 03:01:08 PDT Sergio Martins wrote:
> On 2017-05-17 17:19, Thiago Macieira wrote:
> > Since I am unable to fulfill my duties as maintainer, I am stepping
> > down and
> > opening the way up for someone else.
> Hi Thiago,
> Do you have an overview on what's the current state of the module ? Just
> so the next maintainer gets an idea of where to start.
Currently, the ONE important thing that QtDBus needs is to solve that crash-
on-exit bug. It's been P1 since the new threading model was released in 5.6.0.
After that, the module could be declared Done. It doesn't need much update and
works almost just fine. There may be a couple of other issues that need to be
addressed relating to the threading model, but I haven't received any reports
The biggest problem is that QDBusConnectionManager is a thread that runs until
application exit and it outlives QCoreApplication (that's why QDaemonThread
exists). And this runs into a problem with Windows: whenever ExitProcess is
called, before each DLL's static destructors are run, the threads simply
disappear. So global destructors may try to lock mutexes that are held by
threads that are no longer running and, thus, cause a deadlock. That is the
source of the deadlock that we've been seeing on the CI.
Aside from that, my (dropped) patches were meant to clean up QtDBus. There are
a couple of poor design choices that I made in 2006 that are still present.
But mostly, they were meant to first constrain libdbus-1 requirements to a few
places, as opposed to how they permeate all of QDBusMessage. This is already
done, though there is one regression I know of for a bug that was fixed after I
started developing back in 5.4 and 5.5 days.
Eventually, the goal was to drop the libdbus-1 requirement and implement the
protocol entirely in Qt code. Andreas Hartmetz has a number of patches on top
of mine that go in that direction. But I never reviewed his contributions
because they depended on getting mine out and mine depended on that P1 being
fixed. I also developed a file-descriptor passing functionality for
QNativeSocketEngine but haven't upstreamed that yet. QtDBus would then use
QNativeSocketEngine directly (not QLocalSocket) and Andreas's marshalling and
So, as you can see, everything goes back to the problems that happen at exit,
during global destruction, because QDBusConnectionManager must outlive
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
More information about the Development