---- 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