dbus mini-summit at Desktop Summit 2011

[Simon McVittie]

On Wed, 10 Aug 2011 at 18:12:38 +0200, Will Thompson wrote:
> • Let's declare Simon the maintainer! (If he's okay with that.)

At the moment I'm one of several equal maintainers, and I prefer that
situation, really - if I'm the only maintainer, then there's nobody to nag to
review my patches. (Hint, hint.)

While I've been able to spend a lot of time on libdbus recently, that's
not guaranteed to be the case, particularly after a few months have passed.

If you mean "instead of Havoc's absentee maintainership", I'd rather not
be the default assignee in Bugzilla: I'd much prefer to see a Telepathy-like
arrangement where the default assignee and QA contact are mailing lists,
and the maintainer cabal put a Bugzilla "watch" on those mailing lists
in order to get bugmail.

On Wed, 10 Aug 2011 at 18:48:44 +0200, Thiago Macieira wrote:
> On Wednesday, 10 de August de 2011 18:12:38 Will Thompson wrote:
> > • Split dbus-glib's mainloop integration out and put it in libdbus.
> 
> I don't know if this is what you meant here, but Havoc has said before, and I 
> support him, that libdbus-1 shall not link to glib. QtDBus cannot rely on the 
> glib integration.

I think the intention here is that the dbus source package would build
a small, separate libdbus-gmain-1 if GLib is installed/enabled/whatever;
libdbus-1 would continue to be main-loop-agnostic, but distribution packages
would (in practice) build-depend on GLib, build both libraries, and emit them
as separate binary packages (or subpackages if you like RPM).

I personally think that makes more sense than introducing a new source package
(tarball release, git repo, etc.) just for the GLib main loop integration,
particularly since I'm already using that for many libdbus regression tests,
but if you still strongly object, we could do a tiny parallel project for
libdbus-gmain-1...

> > • Declare that using (eg) _send_with_reply_and_block() in >1 thread is
> > unsupported. We can't actually remove the connection-locking code
> > because QtDBus depends on it working (inasmuch as it works). VLC (for
> > instance) uses one private connection per thread, which should continue
> > to be supported.
> 
> If you meant to declare the function as "thread-unsafe", I can introduce my 
> own locking around it. That way, the function will not be called at the same 
> time from more than one thread.

I've been quite tempted to do a libdbus-2 which is explicitly not at all
thread-safe (each object can only be used from one thread at a time, or
possibly from one thread *ever*), at which point, yes, QtDBus would have to
do its own locking (or maybe we'd introduce a DBusLockedConnection, etc.,
which wraps DBusConnection and re-introduces thread-safety, probably at a
performance/stability/sanity cost). I think that'd be more honest than
just changing libdbus-1's guarantees.

> If you meant that the function should be called always from the same thread, 
> you make my life difficult.

FWIW, this is essentially what GDBus does, by putting all of its D-Bus
dispatching in a worker thread. I realise you'd probably need a lot of work
in QtDBus to do similarly, though.

Will wrote:
> • We could consider exposing a mainloop from libdbus: this might be of
> interest to systemd.

I'm not convinced that DBusLoop is shared-library quality (in particular,
it's not at all thread-safe), but then again, this would save people who're
allergic to GLib and Qt from inventing the world's 573rd half-working
main loop.

(As far as I can tell the typical thought process goes: I want a library that
doesn't depend on a specific main loop implementation, so people can embed it
in any application. I know, I'll write a main loop implementation, then I can
depend on that! ... and people can't embed it in any application that does
things other than D-Bus. OK, that's a problem, so I'll solve it with threads!
Now I have O(n**2) problems and they're all non-deterministic. Why is
computing so hard? *gives up*)

DBusLoop as public API would also mean I could use that instead of GMainLoop
in the regression tests, without breaking the goal of "make most regression
tests only use public API".

> • systemd service activation: Lennart wants to change the code in DBus
> to look for systemd service files rather than needing a dummy
> DBus-format service file.

I think this deserves its own thread, tbh; I realise Lennart wants to make
the world simpler via "everyone uses systemd, and everyone whose kernel isn't
Linux is irrelevant", but at the same time, I think there's a danger of
causing <http://www.xkcd.com/927/> for upstream project authors :-)

    S