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. > 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 _______________________________________________ SyncEvolution mailing list [email protected] http://lists.syncevolution.org/listinfo/syncevolution
