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

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Sébastien Wilmet-2
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
_______________________________________________
gtk-devel-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

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

Christian Hergert
On 09/10/2017 04:27 AM, Sébastien Wilmet wrote:
> If I'm not mistaken, the same problem can happen with NFS-mounted home
> directories.

Some relevant blog posts and mailing list entries from the past.

  http://0pointer.net/blog/projects/locking.html
  http://0pointer.net/blog/projects/locking2.html

Very long thread...

  https://lists.freedesktop.org/archives/dbus/2010-May/012777.html

There was another post I failed to locate, that went into detail on why
none of this stuff works. I think it was from Lennart as well.

-- Christian
_______________________________________________
gtk-devel-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

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

Bastien Nocera
In reply to this post by Sébastien Wilmet-2
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
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

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

Sébastien Wilmet-2
On Mon, Sep 11, 2017 at 02:25:43PM +0200, Bastien Nocera wrote:
> 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.

OK, thanks for the info.
_______________________________________________
gtk-devel-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

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

Sébastien Wilmet-2
In reply to this post by Christian Hergert
On Sun, Sep 10, 2017 at 12:00:28PM -0700, Christian Hergert wrote:

> On 09/10/2017 04:27 AM, Sébastien Wilmet wrote:
> > If I'm not mistaken, the same problem can happen with NFS-mounted home
> > directories.
>
> Some relevant blog posts and mailing list entries from the past.
>
>  http://0pointer.net/blog/projects/locking.html
>  http://0pointer.net/blog/projects/locking2.html
>
> Very long thread...
>
>  https://lists.freedesktop.org/archives/dbus/2010-May/012777.html
>
> There was another post I failed to locate, that went into detail on why none
> of this stuff works. I think it was from Lennart as well.

Thanks for the links, I'll read that later.
_______________________________________________
gtk-devel-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-devel-list