Re: [SyncEvolution] C++ D-Bus bindings + blocking calls (was: Re: DBus server rework: sync, shutdown, and password request)
On Tue, 2012-02-14 at 16:02 +0100, Patrick Ohly wrote:
On Mon, 2012-02-13 at 14:50 +0100, Chris Kühl wrote:
> - Krzesimir implemented the missing functionality in the gio-gdbus
> wrapper and added code to do blocking calls with minimal extra code
> required in consuming classes.
In addition to adding a block() method which executes the call, wouldn't
it be nicer to also overload the call operator such that if there is no
Callback_t parameter, all results are returned directly (special case
for a single return value) or as tuple (general case)?
The block() call would be more efficient for large return values (avoids
one copying), but for small ones the ease of use certainly would be
worth it.
I've experimented a bit with it and think it can be done.
... but there are complications.
When the call operator is called with a boost::function as callback, the
C++ compiler picks the operator implementation which has that type as
last parameter, as intended (more specific alternatives are preferred).
But when the result of boost::bind() is passed to the operator, the
compiler ends up treating it like an arbitrary template class and tries
to serialize it in the blocking call version of the call operator.
To solve this, one would have to add more variants of the call operator
- not nice. I'd prefer to change the C++ binding's API and offer a
blocking call operator and an asynchronous start() call which is
equivalent to the current call operator. Seems cleaner to me.
Is there still a need for the block() variant if there was a
"normal"
blocking call operator()?
I looked again at the concurrent-sync-sessions-r1 branch and found that
the direct calling of the block() methods was already removed again in
favor of some generic callback mechanism which stores the return values
in some bound variables.
I still think that a "normal" method call is much more intuitive. If I
don't hear otherwise, then I'll rewrite the top of the branch to use the
approach outlined above.
--
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.