Starting the kdbus discussions

[Alexander Larsson]

On mån, 2014-01-20 at 06:54 +0800, Andrew Cooks wrote:
> On Sat, Jan 18, 2014 at 3:51 AM, David Zeuthen <zeuthen at gmail.com> wrote:
> > Hi,
> >
> > On Fri, Jan 17, 2014 at 11:33 AM, Lennart Poettering <mzqohf at 0pointer.de> wrote:
> >
> >> What does the worker thread
> >> bring as a benefit over the way libdbus1 handles this?
> >
> > The ability to have multiple threads doing both sync and async calls
> > and have this work without these interfering with each other (for
> > example, a blocking call in one thread should not prevent delivery of
> > D-Bus messages in other threads). In the case of async calls, each
> > thread then run its own mainloop. See
> >
> >  https://git.gnome.org/browse/glib/tree/gio/tests/gdbus-threading.c?id=2.39.3#n340
> >
> > for details. If you want your D-Bus library to do this kind of thing -
> > and in GLib we really do - the straightforward way to do this involves
> > a worker-thread....
> 
> Could you point me to an example of reasonably well designed code that
> mixes sync and async calls?

Take any one reasonably well designed library that uses async call (e.g.
UI code) and one well designed library that uses sync calls (typically
in worker i/o threads). Use both library in one application.

But even using both in one codebase makes a lot of sense. For instance,
Nautilus uses async code for almost all i/o (to avoid blocking the UI),
which will use dbus in the  gvfs case. However, for really complex
operations like recursive directory copies/merges we use sync calls from
a worker thread (that calls out to the UI thread asynchronously). This
makes these complex operations understandable by mere mortals, whereas
an async version of the same would be mindblowingly complex.