Re: Improving API for lists, or wildcarded schemas
- From: Tony Houghton <lists realh co uk>
- To: "gconf-list gnome org" <gconf-list gnome org>
- Subject: Re: Improving API for lists, or wildcarded schemas
- Date: Fri, 30 Jan 2004 21:29:57 +0000
In <20040130203415 9621 30044 polymer turner gestalt entity net>, you wrote:
> On Fri Jan 30 16:33:58 2004, Tony Houghton wrote:
> >I realise locking has the potential for one application to block others,
> >that's why I suggested keeping the lock internal - ie not exposed in the
> >API - and only using it from gconf functions.
>
> Ah, so libgconf would obtain locks on gconfd, but this API wouldn't be
> exposed. Still the same problem, I think - although most badly written
> applications will be running through the library.
If libgconf is written robustly it should be able to effectively
guarantee not to crash while a key is locked.
> >The trouble with conditional store is that it could lead to race
> >conditions.
>
> In what way?
>
> It certainly means that if you have several clients all trying to set a
> certain datum then they may cause each other's conditional stores to fail,
> but that's not a race, per-se, that's the intention.
>
> Admittedly, it does fit the classical definition of a race - that is, that
> the outcome depends on precise timing of events - but in this case, we
> specifically want the outcome to happen this way.
I was imagining it could lead to a loop, but now I think you're right.
For one client to cause another client to have to reread the list, the
first client would have to perform a write and therefore succeed, so a
loop can't be sustained that way after all.
--
TH * http://www.realh.co.uk
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]