12:27 a.m.
On Wed, 2012-02-22 at 14:15 +0100, Chris Kühl wrote:
2012/2/22 Patrick Ohly <patrick.ohly(a)intel.com>:
> On Thu, 2012-02-16 at 15:32 +0100, Chris Kühl wrote:
>> > How is that going?
>> >
>> > I'm now looking more seriously at the code myself.
>>
>> I wouldn't take too close a look at it just yet, I'm still working on
>> getting some fundamental pieces working, like the main loop dance in
>> the helper.
>
> This is based on an older statement of mine:
> "Anything that runs a sync session (i.e. the helper) will have to
> continue doing the g_main_loop dance or become multithreaded, because
> the libsynthesis APIs are not asynchronous."
>
> As we've seen, for example in the simplified command line client of the
> D-Bus server, introducing the blocking method calls considerably
> simplified code which is allowed to block.
>
Can you point me to this commit? I've not been able to track it down.
Knowing the code, I can imagine the changes that would be made,
though.
It's fcdd1b265b on the master branch:
command line: fixed --status and --monitor
The implementation was broken when using GDBus GIO (mismatch between
string and D-Bus object type) and probably also with GDBus libdbus
(missing boolean for GetConfig()).
Rewritten using blocking D-Bus calls, which makes the implementation
also a lot shorter and easier to understand.
It would be good to have automated tests for these features. Not done
yet.
> By definition, anything in a sync session is allowed to block.
There are
> downsides, the main one being stuck in a long-running operation while
> the session is already meant to be aborted, in which case that operation
> should also be aborted.
>
> The recently introduced SuspendFlags class is meant to help with that.
>
> Another downside is that requests from syncevo-dbus-server to the helper
> via D-Bus will not be processed unless the helper runs the main loop at
> least occasionally. Are there any such requests?
>
> So what I am asking now is basically: can we use blocking method calls
> from helper to syncevo-dbus-server and would it help?
>
Right now, as you know, the one-to-one DBus interface is on the helper
process side.
I haven't looked at the internal interface defition(s) at all.
This makes more sense to me because there is currently
only one instance (password request) where the helper is requesting
information from the server process. In this case, we send a signal
and block until the password response DBus method is invoked. But this
is the single instance that the helper process needs to get
information from the server process. Moving the one-to-one DBus
interface to the server process would introduce many more of these
signal/response methods as the server often requests info from the
helper due to the client calls.
Makes sense.
> I think it would help, at least in some cases.
>
> For example, requesting a password can be blocking. In that case it
> would be the job of the syncevo-dbus-server to deny the request when the
> helper is meant to abort. Same for other blocking requests.
>
And we do block here. It's just doing a g_main_context_iteration loop
while waiting for the server to do the Info Request. But like I said,
this is the only instance where this is needed.
Does it handle requests to abort here? How are those communicated? Via
signal or D-Bus call?
> Another alternative would be to include "abort method
call"
> functionality into our blocking D-Bus method call implementation. For
> example, a SIGTERM could be sent to the helper, get caught by
> SuspendFlags and then be detected by the generic code which executes a
> blocking D-Bus call. That might simplify the logic in the
> syncevo-dbus-server (send SIGTERM, wait for helper to terminate).
>
> It would also help the PBAP backend, which now also blocks in a D-Bus
> method call to obexd while the session it participates in might already
> have been aborted.
>
> It makes the D-Bus bindings a bit more difficult, in particular because
> they are meant to be usable without SyncEvolution (not sure whether that
> is still useful). I'm just tossing out the idea so that we can consider
> its merits.
Is there actually an instance of this binding be used outside of
SyncEvolution?
Not at the moment. I don't know whether there is an interest either. I
think it is pretty neat, but SyncEvolution is a bit special by trying to
be "pure C++" without introducing too many external dependencies. Qt C++
developers probably wont' care and just use the Qt binding generator.
Maybe moving out into its own project would help with
that.
Perhaps. Right now I just try to avoid making that impossible.
In short, I don't think this would really help.
Fair enough. It's good to talk about it and record these thoughts.
--
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.