[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[leafnode-list] lockfiles revisited
Some more thoughts about the lockfile implementation of leafnode:
The whole purpose of locking is to make sure that no processes
try to write the groupinfo at the same time or write outdated
information to the groupinfo. This is achieved by obtaining an
fcntl() lock on a file in /var/run/news or failing, if this lock
cannot be acquiered. The problem is that fcntl() works with file
descriptors while unlink(), which is used to delete the lockfile
after the locking process finished, takes the filename as
The idea is now: If the only reason for the lock is to protect
the groupinfo, why not lock groupinfo itself? => No problems with
race conditions between fcntl() and unlinki() calls anymore. Am I
missing something or is this a good idea?
No comments about broken NFS daemons, please.
Fortune cookie of the day:
SHHHH!! I hear SIX TATTOOED TRUCK-DRIVERS tossing ENGINE BLOCKS into
empty OIL DRUMS ...
leafnode-list@xxxxxxxxxxxxxxxxxxxxxxxxxxxx -- mailing list for leafnode
To unsubscribe, send mail with "unsubscribe" in the subject to the list