best practice proposal: name locking and process exclusion

Colin Walters walters at verbum.org
Thu Apr 7 11:08:00 PDT 2011


On Thu, Apr 7, 2011 at 1:52 PM, Lennart Poettering <mzqohf at 0pointer.de> wrote:
>
> You said you wanted this lock to be taken early in the process. I was suggesting that
> actually you want this lock taken *before* the process is actually
> started. Hence bus activation.

Oh, sorry - yep, makes sense.

> It is my plan btw to get rid of this requirement, and make D-Bus
> activate a service by mere presence of a systemd unit file (or XDG
> .desktop file) but I figure that won't help you here much...

Now .desktop files *are* a hard requirement for apps (or at least, I
wouldn't care a lot if GApplication's uniqueness failed if you didn't
install a .desktop file on GNOME), but yeah, I don't think we can make
systemd integration a hard requirement for GLib at least quite yet.

> I think the easiest solution would be to use a lock file in
> XDG_RUNTIME_DIR:

I'm a fan of the runtime dir and think it makes sense, but like
systemd it is very recent (not in Fedora 14 or RHEL 6 to be concrete),
and I do have to consider people using a private backported GLib.  We
could do if (!g_getenv ("XDG_RUNTIME_DIR")) { use_dbus_name_fallback()
} - but I'm not seeing a compelling advantage of lock files over using
a temporary dbus name as a lock anyways.

But this is an implementation detail - the real point I'm trying to
get to is that it's best practice for components and apps to claim
their DBus name late (or just asynchronously) and use another means
(whether that's a lock file, separate dbus lock name, whatever) as an
exclusion mechanism.


More information about the dbus mailing list