Starting the kdbus discussions

[Lennart Poettering]

On Mon, 20.01.14 06:54, Andrew Cooks (acooks at gmail.com) wrote:

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

As long as you don't mix sync/async calls in both directions between the
same services, mixing them is fine. If you know exactly what your
clients are, and to who you are a service, and both sets don't
intersect, it's totally fine to mix them.

Again, synchronous message calls actually are essential for making time
slice gifting and prioritiy inheritance possible, and this is something
we absolutely want, especially for the embedded and
high-load/little-resources usecases.

Basically, in order to pass the CPU time slice and scheduling priority
to a another service during method invocation we need to make sure that
the caller's execution is synchronously stopped during mehtod call
execution. Or to turn this around: if you want to give your CPU
timeslice and scheduling priority to some other process, you cannot also
keep it at the same time, you must step back and pause until the other
side finished using it. You cannot have a cake and eat it too.

Synchronous method calls are a core piece of the kdbus design now, they
enable a certain set of important functionality. Functionality that is
lost if you make everything asynchronous, and that is lost if you make
everythign indirect via a worker thread...

Lennart

-- 
Lennart Poettering, Red Hat