On Fr, 2012-01-13 at 14:29 +0100, Patrick Ohly wrote:
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.
Duh! Turned out that I wasn't returning a proper return boolean in the
"new-connection" handler. The method returned void, which ended up being
a random value in the caller - that explains why it worked sometimes.
Fixed now. After also fixing the handling of asynchronous method
implementation in GDBus GIO, local sync works with it.
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.