[Development] Stepping down as QtDBus maintainer

[Thiago Macieira]

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 
recently. 

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 
demarshalling code.

So, as you can see, everything goes back to the problems that happen at exit, 
during global destruction, because QDBusConnectionManager must outlive 
QCoreApplication.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center