[Syncevolution-issues] [Bug 6376] sync-ui + D-Bus server: implement interactive password requests
http://bugzilla.moblin.org/show_bug.cgi?id=6376
--- Comment #11 from yongsheng zhu <yongsheng.zhu(a)intel.com> 2009-12-17 00:38:18
PST ---
> After reviewing the code, I have a concern. In my opinion, when
doing sync, the
> events from dbus clients dispatched mostly are depending on m_agent->wait() in
> the SyncContext->doSync(), which is, of course, an implicit side-affect.
That's true, but...
> I'm
> afraid that we should give a regular callback provided by cmdline or dbus
> server and call them regularly in our Sync main loop.
... the alternative would require regular polling, which either drains power
(when using no delays) or introduces latencies (when using a large delay
between checking).
Yes, you are right. dependency on m_agent->wait() is a
possible solution in
case of transporting taking much time of the whole sync, which gives many
opportunities to dbus server.
I'd prefer to keep the "block in g_main_loop_run()"
approach working as much as
possible.
> BTW, after discussion with Congwu, we found a potential issue for glib main
> loop on transporting agents.
> If aborting happens by dbus clients, obex transporting agent has to wait for at
> least one response of obexd and then aborting will be handled but for http
> agent, it would be handled without this kind of blocking.
"obex transporting agent" = DBusTransportAgent? There is a "TODO: setup
regular
callback" in DBusTransportAgent::wait() about that - not filed in Bugzilla yet,
though.
No, it's ObexTransportAgent. There are 2 issues:
1) busy loop: in ObexTransportAgent.wait(), g_main_context_iteration is not
blocked, but it need wait for obex response. so the while statement makes a
busy loop. It could be fixed with blocked version of g_main_context_iteration.
while (!m_obexReady) {
g_main_context_iteration (NULL, FALSE);
...
}
2) There is a timeout function to check whether to abort or suspend the sync
though checking the global flags(internally set by signal handler). However,
dbus server might receive 'abort' events from server and sets them in
DBusSync.checkForAbort/checkForSuspend callbacks. SyncContext will regually
call it. So for this, ObexTransportAgent has to wait for at least one response
from OBEXD. This is not so reasonable. ObexTransportAgent timeout function
should invoke checkForAbort/checkForSuspend instead of arbitrarily reading
internal global flags.
--
Configure bugmail: http://bugzilla.moblin.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching someone on the CC list of the bug.