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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, 2004-11-30 at 14:16 -0600, Chris Adams wrote:
> Once upon a time, Neal D. Becker <ndbecker2@xxxxxxxxxxx> said:
> > Are you sure?  What if you:
> > 1) duplicate the directory (using hardlinks to files)
> > 2) atomic rename directory
> 
> You can't do step #2.  You can only rename over an existing directory if
> the directory is already empty.
> 
> The only way you can do something like what you say is if you create the
> directories under a different name and use symlinks to point to them
> (you can replace a symlink atomically by creating a new symlink under a
> new name and then renaming the symlink over the old one).

Would this actually be atomic?  What if two apps tried doing this at
once?  One makes db-1 as the temp work directory, another makes db-2 as
the temp dir, and then whoever makes the symlink last gets the symlink
pointing to their data, resulting in the previous process' changes being
silently lost.

You'd have to do locking, which I noted the problems with (NFS in
particular) in my other mail.

Or, if Elektra were to use a daemon that centralizes access, you
wouldn't need the locking (only one process doing this at a time), but
Elektra won't do that for several sort-of-almost good reasons of early
bootup.  (I suppose if the DB is read-only you can do without the
daemon, and early bootup probably would be read-only, so you can have
Elektra start the daemon later on, but I'm not sure how well that would
work either - yet more race conditions between apps reading something
when the daemon starts and potentially starts changing stuff.)

> 
> If you go that way, you have to have a clean-up program.  Otherwise,
> unclean shutdowns (either of the management program(s) or of the system)
> will leave stuff all over the place.  You could use a log to make the
> clean-up faster, and rotate the log out when it is processed (i.e. along
> the lines of db_checkpoint and db_archive from BDB).
> 
> -- 
> Chris Adams <cmadams@xxxxxxxxxx>
> Systems and Network Administrator - HiWAAY Internet Services
> I don't speak for anybody but myself - that's enough trouble.
> 
-- 
Sean Middleditch <elanthis@xxxxxxxxxxxxxxx>
AwesomePlay Productions, Inc.


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux