dbus-cplusplus-devel

Re: [dbus-cplusplus-devel] D-Bus C++

[Andreas V. <li...@br...>]

Am Tue, 10 Mar 2009 14:40:18 +0000 schrieb Markus Kohler:

> Hello Paolo and Andreas,
> 
> besides two other bugs, I found a new one recently and tried to track
> it down. I am not sure whether it is a bug in D-Bus-C++ or (more
> likely) in libdbus. It looks like a deadlock. Constellation is the
> following:
> 
> Given:
> - application APP that implements the adaptor for interface A, the
> proxy for interface B (with methods and signals) and uses class C
> (standard C++ class)
> - B has, let's say, a method Create and a signal Created, i.e. in B's
> adaptor Create will call this-> Created to emit the signal
> - adaptor class of interface A uses method Create from interface B's
> proxy and method M from class C
> - class C implements interface B's proxy (to get notified about
> changes), i.e. implements callback function Created for interface B
> - class C's method M calls another methods of interface B's proxy
> (not Create)
> 
> This constellation makes application APP hang. Because of the
> "circular" arrangement it may be a deadlock but I could not find out
> more at this moment in time.
> 
> If I disable in adaptor of interface B "this->Created" call
> everything works fine.
> 
> Right now I think of separating the interface of B into two
> interfaces one with signals and one with methods which may help.

This is what I do for my application.

> Do you have a Bugtracker up where you collect this type of
> information? I looked at your official DBus page
> http://freedesktop.org/wiki/Software/dbus-c%2B%2B which points to
> Bugzilla. However there I could not find any activity on dbus-c++
> (only dbus c-lib).

Use this one:

http://sourceforge.net/tracker/?group_id=236997&atid=1101682

But please mark the "Group" which branch it is.

> Best regards,
> Markus
> 
> ps. the echo example of the newest d-bus-c++ that I pulled from git
> still does not work: if you compile and use the echo-client it
> behaves random in the way that it outputs sometimes all Hello echos,
> sometimes only the onces from the first thread and so on. I believe
> it has to do with Bug 857 at
> http://bugs.freedesktop.org/attachment.cgi?id=22759&action=edit where
> it says: "We're not currently threadsafe, and the documentation
> should really reflect that.  Even better would be to fix it of
> course."

I also played around with the echo example and had various threading
problems. As long as you use the own main loop dispatcher you'll get
those problem. You should use the glib or ecore integration to get it
working.

I've some ideas to get the Dbus-C++ main loop working also with
threads. But you're right the echo example is broken currently. Don't
use it currently or change it to use glib and provide a patch.

regards
Andreas

Re: [dbus-cplusplus-devel] D-Bus C++

[Meier, A. <and...@sc...>]

Hello,

> ...
> I also played around with the echo example and had various threading
> problems. As long as you use the own main loop dispatcher you'll get
> those problem. You should use the glib or ecore integration to get it
> working.
> 
> I've some ideas to get the Dbus-C++ main loop working also with
> threads. But you're right the echo example is broken currently. Don't
> use it currently or change it to use glib and provide a patch.

In the end I would like to have a client-side application with a main
loop
and various threads from where blocking method calls are invoked.

I started with the echo-example and found it broken.

I would be glad if you could describe your previously mentioned ideas in
short terms? So I have a better understanding of where to start looking
for the problem.

Best regards,
Andreas

Re: [dbus-cplusplus-devel] D-Bus C++

[Andreas V. <li...@br...>]

Am Mon, 18 May 2009 15:22:24 +0200 schrieb Meier, Andreas:

> Hello,
> 
> > ...
> > I also played around with the echo example and had various threading
> > problems. As long as you use the own main loop dispatcher you'll get
> > those problem. You should use the glib or ecore integration to get
> > it working.
> > 
> > I've some ideas to get the Dbus-C++ main loop working also with
> > threads. But you're right the echo example is broken currently.
> > Don't use it currently or change it to use glib and provide a patch.
> 
> In the end I would like to have a client-side application with a main
> loop
> and various threads from where blocking method calls are invoked.
> 
> I started with the echo-example and found it broken.
> 
> I would be glad if you could describe your previously mentioned ideas
> in short terms? So I have a better understanding of where to start
> looking for the problem.

Hello Andreas,

The problem is to get a hook from the event loop where it's save to
queue new requests in dbus-c++. In the Glib and Ecore there's a real
event loop. So I would do it in dispatcher.cpp:

void BusDispatcher::enter()
{
	debug_log("entering dispatcher %p", this);

	_running = true;

	while (_running)
	{
		// -> call the callback here!
		do_iteration();
	}

	debug_log("leaving dispatcher %p", this);
}

The while loop there is our main event loop. So as long as Dbus-C++
isn't complete thread save it's only save to queue new requests outside
the do_iteration() function. So far the theory... :-)

I would add a function callback to the prototype of enter(). Then in
the loop before the do_iteration() I would call that callback function.

Then in the e.g. echo example you've this callback function from where
it's save to call Dbus-C++ functions. So here is a snippet from the
echo client:

void *greeter_thread(void *arg)
{
	DBus::Connection *conn = reinterpret_cast<DBus::Connection
*>(arg);

	EchoClient client(*conn, ECHO_SERVER_PATH, ECHO_SERVER_NAME);

	char idstr[16];
	string s ("TestString");
	
	snprintf(idstr, sizeof(idstr), "%lu", pthread_self());

	for (int i = 0; i < 1000 && spin; ++i)
	{
		cout << client.Echo(s) << endl;
	}
	
	cout << idstr << " done " << endl;

	return NULL;
}

I would create a queue protected by a mutex and queue requests from the
thread and work on this queue in the callback function. So it's sure to
call a Dbus-C++ function.

I would try it this way. But sorry I'm busy with another project. But
if you had success I'll commit your patches into both branches.

regards
Andreas

Re: [dbus-cplusplus-devel] D-Bus C++

[Andreas V. <li...@br...>]

Am Tue, 26 May 2009 14:21:35 +0200 schrieb Meier, Andreas:

Hello Andreas,

I created the version with Ecore integration in the gitorious branch.
So if you've problems report them here. I would like to get more
feedback about it. If it works for several persons I'll integrate it
into the main branch on fd.org.

It's not much work to change the Echo example to Ecore main loop.

It works the same way as the glib dispatcher.

But take caution with the threads in the example. Also the Ecore
binding is not thread safe! But as long as you call a Dbus-C++ function
from within a Ecore loop callback there will be no problems.

regards
Andreas

> Hello Andreas
> 
> Thank you for your quick answer.
> 
> Fixing the dbus-C++ main-loop was my first idea. Then I learnt of the
> existence of the dbus-cplusplus bindings with integrated ecore main
> loop. In the meantime I was having a look at that package...
> 
> But after patching the echo example client based on the ecore example
> (exchanging DBus::BusDispatcher with DBus::Ecore::BusDispatcher
> and introducing ecore main loop handling) it is still failing.
> Or is it more complicated to rewrite the echo example to work with the
> ecore main loop?
> 
> > ...
> > I also played around with the echo example and had various threading
> > problems. As long as you use the own main loop dispatcher you'll get
> > those problem. You should use the glib or ecore integration to get
> > it working.
> >
> > I've some ideas to get the Dbus-C++ main loop working also with
> > threads. But you're right the echo example is broken currently.
> > Don't use it currently or change it to use glib and provide a patch.
> > ...
> 
> You stated that one should use glib or ecore integration and a
> sentence further down you mention glib only. Is the glib integration
> better tested
> than the ecore one? The ecore integration is more appealing to me
> since its memory footprint is much smaller.
> 
> What do you think is more promising with a limited time budget? Fixing
> multi-threading issue of dbus-C++ or debugging dbus-cplusplus with
> ecore integration?
> 
> Have a good day,
> Andreas
>