Re: [Evolution-hackers] Regarding API breakage and lost test cases

[Matthew Barnes <mbarnes redhat com>]

On Fri, 2012-10-05 at 22:19 +0900, Tristan Van Berkom wrote:
>    a.) e_source_registry_commit_source_sync() seems not exactly
>        very sync. I haven't looked into that in detail but
>        surely the registry server needs to block on something else
>        before sending the reply.

The issue is on the client side in ESourceRegistry.  I had some pretty
nasty code at one time to deal with this but must have yanked it while
reworking the APIs.

Even after the remote method call completes, ESourceRegistry will still
have to stop and wait for an "object-added" signal from its internal
GDBusObjectManagerClient, which is running in its own isolated thread.
The "object-added" signal has the new GDBusObject needed to build the
new ESource instance.  And it can't complete on just any "object-added"
signal -- it has to be the "object-added" signal corresponding to the
scratch ESource that was just submitted.

I'll see if I can restore that nastiness again in 3.7.x.


>        However, the e-source-registry user facing APIs seem to make an
>        attempt at doing this internally (i.e. it has it's own thread
>        and mainloop presumably intended to handle the dbus messages as
>        a convenience to the caller), so... probably just a minor
>        detail or bug to fix there...

The GDBusObjectManagerClient only emits signals from the GMainContext
that was the thread-default at creation time.  So it's created in its
own dedicated thread to ensure its signal emissions cannot be inhibited
by something pushing a different thread-default GMainContext.  Otherwise
deadlocks occur when an ESourceRegistry method has to stop and wait for
a signal emission from the GDBusObjectManagerClient, such as in the case
described above.

Matthew Barnes