Bug 52749 - improve integration of suspend/abort with transports
Summary: improve integration of suspend/abort with transports
Status: RESOLVED MOVED
Alias: None
Product: SyncEvolution
Classification: Unclassified
Component: SyncEvolution (show other bugs)
Version: unspecified
Hardware: All All
: medium enhancement
Assignee: SyncEvolution Community
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-04-26 19:43 UTC by SyncEvolution Community
Modified: 2018-10-13 12:44 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments

Description Patrick Ohly 2012-07-29 18:36:00 UTC


---- Reported by jingke.zhang@intel.com 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
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.



--- Bug imported by patrick.ohly@gmx.de 2012-07-29 20:36 UTC  ---

This bug was previously known as _bug_ 1362 at https://bugs.meego.com/show_bug.cgi?id=1362
Comment 1 Patrick Ohly 2012-08-07 08:04:47 UTC
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.
Comment 2 Patrick Ohly 2014-07-23 13:12:42 UTC
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.
Comment 3 GitLab Migration User 2018-10-13 12:44:06 UTC
-- 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.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.