Re: GConf Backing Locking

[Havoc Pennington <hp redhat com>]

Hi,

Because gconfd writes are already atomic (you won't get half of one
daemon's file and half of another's), locking "as needed" I don't think
adds anything; you could as easily not lock at all and have an
equivalent situation. In fact GCONF_LOCAL_LOCKS=1 (the GNOME 2.4
default) is an equivalent situation. Only GNOME 2.2 still locks that IOR
file AFAIK.

What isn't addressed by this is the problem of inconsistent database
state; i.e. panel in login session A writes half its settings and panel
in login session B writes half its settings. That is the hard problem to
solve, and one clean solution is to support a gconf server used by both
login sessions, as discussed in my OLS paper from a couple of years ago.

There may be other solutions, which I would welcome hearing about.

Havoc