Re: Locking

[Havoc Pennington <hp redhat com>]

Julian King <jpk28 cus cam ac uk> writes: 
> In particular we believe that (and the documentation hints strongly that 
> this is the case) there should only ever be one gconfd, and that all file
> manipulation on locked files should be done through this one instance of 
> gconfd.
> 
> Could someone confirm that this is the intent?

Indeed, as Michael says. If you have two gconfd processes, everything
breaks.

If you are willing to limit each user's logins to one computer, a
really simple solution is to move the lock to /tmp or /var which is
normally a standard, local filesystem.

The consequence of the user logging in twice will then be that apps
may see somewhat nonsensical configuration state; for example the last
value change notification they received may have contained a different
value for the setting than they would get if they actively queried the
setting. But you probably would not notice the problem very often, it
would manifest as the occasional bit of weirdness. (I think. It's
possible that for complicated configuration like the GNOME panel
things could get significantly broken by saving half of one config and
half of the other. But should be hard to do unless the user is
actively configuring things in two places at once at the same moment.)
 
> a) Select at compile time
> b) Select at run time via a configuration option
> c) Select at run time via a command line option
> d) (b) and (c) both options
> e) Something else I've not thought of.

I think a) would generally be right, but b) sounds fine too. The way
gconfd gets run c) doesn't really work out. e) might be good, who
knows. ;-)

So the simple start is a --with-per-machine-lock configure option; if
you can come up with a in-the-users-home-dir locking scheme that
works, I'd be impressed (I have no idea how to do this without getting
stale locks fairly often).

Havoc