Elektrified X.org released (was: X configuration paradigm, and a proposal)

[Sean Middleditch]

On Tue, 2004-11-30 at 14:24 -0500, Neal D. Becker wrote:
> Sean Middleditch wrote:
> 
> [...]
> > So far as implementation, this really is easy even with a (single) file-
> > based backend.  Robustness might take some work, but the basics are
> > easy.  You simply keep a list of all they keys that have been set, and
> > when the Commit command comes along, lock the file(s) in question and
> > modify them.  On Rollback, just "forget" all the key changes that
> > haven't been committed yet.  Basically the hard part for the simple file
> > backend is getting the commit to stay atomic on errors when you use
> > multiple files.  If you have multiple files being changed, I don't
> > believe it's actually possible to be 100% atomic - you can reduce the
> > chances of something breaking, but there will always be various race
> > conditions in regards to when errors occur that could leave you in a
> > half-committed state.
> > 
> 
> rename is atomic.  You can always use this fact if you need to.

Yes.  That doesn't help with the problem of making atomic commits to
*multiple* files.  You would have to perform multiple renames, of which
some may succeed and others may fail for any of a number of reasons, and
then you can't necessarily undo the ones you already did.  Unless there
is a way to do an atomic rename of multiple files, my point definitely
still stands - multiple files cannot be modified atomically.

> 
-- 
Sean Middleditch <elanthis at awesomeplay.com>
AwesomePlay Productions, Inc.