http://bugs.meego.com/show_bug.cgi?id=1362 Summary: improve integration of suspend/abort with transports Classification: MeeGo Projects Product: SyncEvolution Version: unspecified Platform: Netbook OS/Version: IA Status: ASSIGNED Severity: normal Priority: Medium Component: SyncEvolution AssignedTo: syncevolution-bugs(a)meego.bugs ReportedBy: jingke.zhang(a)intel.com QAContact: jingke.zhang(a)intel.com CC: syncevolution-bugs(a)meego.bugs, syncevolution-default-bugs(a)meego.bugs Estimated Hours: 0.0 This is from http://bugzilla.moblin.org/show_bug.cgi?id=8730 Description From pohly 2009-12-17 09:37:55 PST (-) [reply] Discussion started as part of bug #6376. Congwu pointed out that the ObexTransportAgent has to use polling to check for the internal suspend/abort flags (SyncContext::getSuspendFlags()). This ignores abort requests coming in via the D-Bus API, which are only checked at the higher layers once the ObexTransportAgent returns because it has data. The DBusTransportAgent also has a TODO around adding the regular callbacks into the caller. I think it does not check the abort request triggered by signals, which depends on these callbacks. Here's an idea for a better architecture: - instead of using global SuspendFlags, introduce two pipes, one for suspend, one for abort - the signal handler writes one byte into one end of these to flag "suspend and/or abort requested" - so does the D-Bus API implementation - the other end of the pipes can be checked for readability *without* actually reading the byte - most event systems can watch for a file descriptor, so we can (but don't have to) get rid of polling ------- Comment #1 From yongsheng zhu 2009-12-17 18:27:34 PST (-) [reply] ------- It's a smarter solution to make logic clear. Then 6376 could also use this solution and don't need to check abort/suspend regually. My think is: wrap all these behaviors in 2 static methods(addSources, Callback), then callers, like dbus server could use it easily.( I guess there should be many places that have to follow this way) I've learned that you think about multithreading, see http://lists.syncevolution.org/pipermail/syncevolution/2009-November/0006... If multithreading, other threads may use main contexts other default context. I wonder whether the two sources of two pipes could be used in more than one GMainContext. ------- Comment #2 From pohly 2009-12-17 23:19:41 PST (-) [reply] ------- (In reply to comment #1) A glib specific instance might be tied to a specific GMainContext; not sure. But the underlying pipe definitely could be used multiple times, as long as we don't let any of the readers drain the pipe. -- Configure bugmail: http://bugs.meego.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching the assignee of the bug. You are watching someone on the CC list of the bug.