GApplication process uniqueness, saving config files and multi-seat support
- Date: Sun, 10 Sep 2017 13:27:26 +0200
- From: Sébastien Wilmet <swilmet@xxxxxxxxx>
- Subject: GApplication process uniqueness, saving config files and multi-seat support
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
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
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*.
- 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?
gtk-devel-list mailing list