On Wed, 2012-02-22 at 14:15 +0100, Chris Kühl wrote:
> 2012/2/22 Patrick Ohly <[email protected]>:
> > 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.
_______________________________________________
SyncEvolution mailing list
[email protected]
http://lists.syncevolution.org/listinfo/syncevolution
