On Mo, 2012-01-09 at 18:59 +0100, Chris Kühl wrote:
> Chris, do you want me to take a stab at adapting GDBus GIO to
> GDBus libdbus changes (local D-Bus connection, API
In order to avoid distraction, I was intending to do this only once
concurrent session is working with the libdbus implementation.
However, I can see that if you want to go ahead and merge you local
sync code into master that would need to be done first. So, feel free
to do that.
I got distracted this week with SyncEvolution maintenance work (there
might be a 1.2.2 soon) and battled with a cold - I'm finally winning :-0
Today I finally got around to it. See updated "fork-exec" branch and in
particular this commit:
Author: Patrick Ohly <patrick.ohly(a)intel.com>
Date: Fri Jan 13 14:19:51 2012 +0100
GDBus GIO: implemented client/server
This pretty much follows the example from:
However, there seems to be a race condition, perhaps related to
multithreading (messages are processed in a second thread by GIO):
"valgrind test/dbus-client-server --forkexec" works, whereas without
valgrind the call either times out or fails with "No methods
registered with this name" in the server's MethodHandler::handler()
Not usable at the moment.
I'm stuck on that. Unless someone has a better idea, I'll have to start
compiling a debug version of glib and look into GIO GDBus.
"strace -f" (yes, you need to watched more than one process) on the
server side shows that the method call is received in thread #1, but it
never shows up in thread #0 (the main one where the connection was
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.