On 07/10/2009 05:18 AM, Jiri Moskovcak wrote: > Hi, > in our project ABRT we use DBUS for communication between ABRT daemon > and client (gui), the problem is that when I ask daemon to do some > time-consuming work the server is blocked until the work is done. So I > want to use threads and that's where I found the catch. > > Here is my idea: > 1. client calls remote method foo() over dbus > 2. daemon receives the call, creates the thread and let it do the work > in background and serve other requests > 3. when the work is finished send reply to the client > - this is the part where I'm stuck, because I want to send the reply as > return message to the matching method call, but the method call already > returned when I started the thread. (So far I can achieve this by > sending signal with return value as an argument, but I don't think this > is a good solution). > > I use dbus-c++, so maybe the answer is in some low-level DBUS API. > > Thanks for any help, > Jirka > Take a look at upstart's trunk. It uses the C API, but usually if you know how to do it with that you can find the corresponding features in the higher level wrapper pretty easily. Upstart is single-threaded, but spawns other processes as part of its operation which it occasionally has to wait for before returning a result. The typical case is: 1) Client calls start() method for a service 2) init gets start method, but doesn't send back a return value. It forks and execs the new service and waits for it to become ready. 3) Service signals that its running. init allows the DBus method to return with the status. --CJD -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
