On Thu, 2012-02-16 at 15:32 +0100, Chris Kühl wrote:
> > One thing which
> > caught my attention is how blocking D-Bus calls are used in
> > syncevo-dbus-server.
> >
> > For example, ConnectionResource::process(): it passes the incoming data
> > on to the helper process with a blocking call. Isn't that a big no-no?
> >
>
> Yes, in this instance the client is expecting the the Reply signal so
> we can definitely do without this blocking call. This is actually how
> I wish the entire DBus interface worked; make a request and wait for a
> signal that delivers the requested data.
But that's already how D-Bus works: send a method call method, get a
reply message back. There's no need to define the D-Bus interface as
"method call without a reply + signal".
> > If the helper is busy, won't that D-Bus call completely block all
> > processing of any other events in the server for considerable periods of
> > time? Worse, if syncevo-dbus-server is blocked in a call to the helper
> > and the helper needs something from syncevo-dbus-server (like a
> > password), then we have a deadlock.
>
> True, this a problem and would require breaking the DBus interface to
> work. The only way I know how to get around this is the make the
> public DBus interface asynchronous.
No, just make the implementation of the D-Bus interface asynchronous.
The C++ bindings support that:
* Asynchronous methods are possible by declaring one parameter as a
* Result pointer and later calling the virtual function provided by
* it. Parameter passing of results is less flexible than that of
* method parameters: the later allows both std::string as well as
* const std::string &, for results only the const reference is
* supported. The Result instance is passed as pointer and then owned
* by the called method.
Have a look at Result1 in src/gdbusxx/test/example.cpp.
The flow of messages then becomes:
1. syncevo-dbus-server receives method call, stores Result pointer
2. syncevo-dbus-server sends method call to helper
3. helper receives method call, replies (asynchronously or
synchronously)
4. syncevo-dbus-server receives reply
5. syncevo-dbus-server relays reply to original caller
I'll see whether I can cook up a patch.
--
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
