Re: Improving API for lists, or wildcarded schemas



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]