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



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.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]