Re: GApplication process uniqueness, saving config files and multi-seat support
- Date: Mon, 11 Sep 2017 14:25:43 +0200
- From: Bastien Nocera <hadess@xxxxxxxxxx>
- Subject: Re: GApplication process uniqueness, saving config files and multi-seat support
On Sun, 2017-09-10 at 13:27 +0200, Sébastien Wilmet wrote:
> With GApplication process uniqueness, an application has a unique
> process per user *session*. But with multi-seat support, it is
> AFAIK to open several graphical sessions for the same user.
> Some GTK+ apps save some config/data in e.g. XML files for stuff that
> don't fit well in GSettings, saved typically in ~/.config/ or
> So it means that if the same app is opened for the same user in two
> different sessions, several processes can write to the same XML file,
> there can be races, and ideally the app needs to synchronize its
> wrt the XML file.
> I think a lot of applications don't cope well with that situation.
> If I'm not mistaken, the same problem can happen with NFS-mounted
> So I think in those setups, there are a lot of potential bugs in GTK+
> applications, because developers (prefer to) think that process
> uniqueness is per *user*.
> Some questions:
> - Does the problem really exists?
> - Is there a recommended way to handle that situation?
> - Is there a way to test easily the situation without multi-seat
> hardware? E.g. with VMs. Something automated, to also being able to
> write unit/integration tests, or something that e.g. GNOME
> could launch easily.
> - Or nobody cares about that problem?
As a general rule, we don't support being logged in to the same account
on 2 different seats, whether they share the same physical machine, or
just the backing storage.
On physical machines, this is enforced by gdm, and a shared user D-Bus,
which mimicks the old session bus.
In short, not something to worry about.
gtk-devel-list mailing list