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 _______________________________________________ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers