12:15 a.m.
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.
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. 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.
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.
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? Maybe moving out into its own project would help with
that.
Chris, you are the one designing the syncevo-dbus-server <-> helper
interaction and know where the pain points are. If changes in the
infrastructure will help, by all means, let's do that.
At this point, the changes required to do the g_main_loop dance are
*far* less than those that are required to move the one-to-one DBus
interface to the server process. As I've said, I think it's actually
better to keep the interface in the helper.
In short, I don't think this would really help.
Cheers,
Chris