Re: [SyncEvolution] Syncevolution build system conversion

2012-01-13 Thread Patrick Ohly
On Do, 2012-01-05 at 16:55 +0100, Murray Cumming wrote:
> As far as I can tell, this patch should be applied. Or is there some
> reason to compile the code in dbus/ if --enable-dbus-service is not
> used?

For a while I compiled sync-ui and core SyncEvolution separately in
MeeGo. In that case, D-Bus service is disabled and dbus/glib needs to be
compiled.

In other words, decoupling dbus compilation from D-Bus service
compilation makes sense. But probably some of the current checks for
what needs to be compiled inside dbus are not quite correct, because
there is no real "enable/disable D-Bus" switch in configure.

-- 
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
SyncEvolution@syncevolution.org
http://lists.syncevolution.org/listinfo/syncevolution


Re: [SyncEvolution] syncevo-dbus-server + forking processes

2012-01-13 Thread Patrick Ohly
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 
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
SyncEvolution@syncevolution.org
http://lists.syncevolution.org/listinfo/syncevolution