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. _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
