Re: Improving API for lists, or wildcarded schemas

["Dave Cridland [Home]" <dave cridland net>]

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.

> 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.

For the list operations you're proposing, libgconf could simply handle the 
error and retry.

An internal lock to libgconf doesn't solve the case where two applications 
see a list as not containing a certain value they require, and both adding it 
- effectively simultaneously. Then that value gets duplicated in the list. 
And that *is* a race, at least in my book.

Of course, it's unlikely to happen often, but it'd be a pain to deal with.

Dave.