---- Reported by firstname.lastname@example.org 2010-04-26 19:43:13 +0000 ----
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 https://bugs.meego.com/show_bug.cgi?id=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
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
------- 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
> 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
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.
--- Bug imported by email@example.com 2012-07-29 20:36 UTC ---
This bug was previously known as _bug_ 1362 at https://bugs.meego.com/show_bug.cgi?id=1362
The SuspendFlags combine abort/suspend requests via signals and D-Bus. Resolved in principle, except that some transports (libneon in WebDAV, ActiveSync while blocked in D-Bus) do not yet check these flags in a timely manner.
For WebDAV, see http://lists.manyfish.co.uk/pipermail/neon/2013-February/001533.html
In a nutshell, new Neon API calls would be needed to interrupt a running WebDAV request when asked to suspend or abort. It may be easier to switch to something else, like libsoup :-/
I'm putting this on hold for now.
-- GitLab Migration Automatic Message --
This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.
You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/SyncEvolution/syncevolution/issues/121.