Several changes, primarily to make this more robust. So far, no more

locking problems.  JV please eyeball...

1. Got rid of is_locked attribute.  Test for locking makes an explicit
   test that a) the tmpfname exists and b) the pid read from the file
   is our pid.  This means that two instances of FileLock in the same
   process that share the same lockfile will always be locked and
   unlocked together (probably doesn't occur except in testing).

2. Added an __del__() which unlocks

3. Moved the creation of the basic lockfile to __kickstart() and added
   a force argument.  When force is true (default is false), the
   lockfile is first removed then recreated.  This is only used if the
   lockfile contains bogus data, such that the winner could not be
   determined.  In that case, the only way to "break" the lock is to
   recreate a new basic lockfile.  This could potentially leave
   tmpfname turds, but in reality this shouldn't happen very often.

4. Encapsulate reading and writing of the lockfile into __write() and
   __read(), so that (most importantly) the umask will be set
   correctly.  This should fix most of the permission problems
   associated with the lockfile by assuring that they are group
   writable.  A side effect: don't eval() the contents of the
   lockfile.

5. lock(): Use the above changes.  Added an assert for what I think is
   an invariant: that the winner filename better not be equal to
   self.tmpfname.  Moved the timeout check into an else clause of the
   pid comparison and eliminated the check of hung_timeout > 0 (this
   is the one I'm least sure about).

0 files changed, 0 insertions, 0 deletions