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

[Sébastien Wilmet <swilmet gnome org>]

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?

--
Sébastien