[Syncevolution-issues] [Bug 8730] New: improve integration of suspend/abort with transports

http://bugzilla.moblin.org/show_bug.cgi?id=8730 Summary: improve integration of suspend/abort with transports Classification: Moblin Projects Product: SyncEvolution Version: upstream Platform: Netbook OS/Version: Moblin Linux Status: ASSIGNED Severity: normal Priority: Undecided Component: *Feature Request AssignedTo: syncevolution(a)lists.intel.com ReportedBy: patrick.ohly(a)intel.com CC: syncevolution(a)lists.intel.com 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 -- Configure bugmail: http://bugzilla.moblin.org/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.