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 the
> recent
> > GDBus libdbus changes (local D-Bus connection, API
> > changes/improvements)?
> >
> 
> 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:

commit 22b8e3286451b43ac9914eafde725e5d8a45fe27
Author: Patrick Ohly <[email protected]>
Date:   Fri Jan 13 14:19:51 2012 +0100

    GDBus GIO: implemented client/server
    
    This pretty much follows the example from:
    http://developer.gnome.org/gio/2.28/GDBusServer.html#GDBusServer.description
    
    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()
    (occurs rarely).
    
    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
established).


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


_______________________________________________
SyncEvolution mailing list
[email protected]
http://lists.syncevolution.org/listinfo/syncevolution

Reply via email to