Re: [SyncEvolution] DBus server rework: syncevo-dbus-server <-> helper communication

On Thu, 2012-02-16 at 15:32 +0100, Chris Kühl wrote: 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. 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? 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. 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. 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. -- 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.