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: [email protected]
ReportedBy: [email protected]
QAContact: [email protected]
CC: [email protected],
[email protected]
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]
-------
> 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
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/000636.html
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)
> I've learned that you think about multithreading, see
> http://lists.syncevolution.org/pipermail/syncevolution/2009-November/000636.html
> 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.
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.
_______________________________________________
Syncevolution-issues mailing list
[email protected]
http://lists.syncevolution.org/listinfo/syncevolution-issues
