[Syncevolution-issues] [Bug 8730] improve integration of suspend/abort with transports
http://bugzilla.moblin.org/show_bug.cgi?id=8730
yongsheng zhu <yongsheng.zhu(a)intel.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |yongsheng.zhu(a)intel.com
--- Comment #1 from yongsheng zhu <yongsheng.zhu(a)intel.com> 2009-12-17 18:27:34 PST
---
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/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.
--
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.