Re: GApplication process uniqueness, saving config files and multi-seat support

[Bastien Nocera <hadess hadess net>]

On Sun, 2017-09-10 at 13:27 +0200, Sébastien Wilmet wrote:
> Hi,
>
> With GApplication process uniqueness, an application has a unique
> process per user *session*. But with multi-seat support, it is
> possible
> 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
> ~/.local/share/.
>
> 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,
> so
> there can be races, and ideally the app needs to synchronize its
> state
> 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
> home
> directories.
>
> 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
> developers
>   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.