[ditrack commit] r1635 - in src/trunk/DITrack: DB Util
Ivan Glushkov
gli.work at gmail.com
Wed Jun 6 08:44:11 PDT 2007
On 6/5/07, Vlad Skvortsov <vss at 73rus.com> wrote:
> gli at ditrack.org wrote:
> > Author: gli
> > Date: 2007-06-01 13:41:44 -0700 (Fri, 01 Jun 2007)
> > New Revision: 1635
> >
> > Modified:
> > src/trunk/DITrack/DB/Common.py
> > src/trunk/DITrack/Util/Locking.py
> > Log:
> > fixing i#52. New low level lock function.
> >
> > Modified: src/trunk/DITrack/DB/Common.py
> > ===================================================================
> > --- src/trunk/DITrack/DB/Common.py 2007-05-28 19:36:12 UTC (rev 1634)
> > +++ src/trunk/DITrack/DB/Common.py 2007-06-01 20:41:44 UTC (rev 1635)
> > @@ -127,6 +127,8 @@
> > The PATH is not a directory.
> > """
> >
> > + self.lock = None
> > + self.lockfo = None
> >
>
> Do we actually need this .lockfo? Can't we just pass it to the lock
> constructor without storing in our object?
surely not.
removed in r1649.
>
> > assert (mode == "r") or (mode == "w"), mode
> >
> > # Check that it's a directory.
> > @@ -143,14 +145,14 @@
> > if v != FORMAT_VERSION:
> > raise DITrack.DB.Exceptions.InvalidVersionError
> >
> > - # XXX: to be removed, mode should be used everywhere instead
> > - if mode == "r":
> > - readonly_mode = True
> > - else:
> > - readonly_mode = False
> > + # Creating local ditrack dir
> > + datadir = os.path.join(path, LOCAL_DT_DIR)
> > + if not os.path.exists(datadir):
> > + os.mkdir(datadir, 0755)
> >
> > # Lock database
> > - self.lockfd = DITrack.Util.Locking.lock(path, readonly_mode)
> > + self.lockfo = open(os.path.join(path, LOCAL_DT_DIR, LOCK_FILE), "w")
> > + self.lock = DITrack.Util.Locking.lock(self.lockfo, mode)
> >
> > # Read up the configuration.
> > self.cfg = DITrack.DB.Configuration.Configuration(path, username)
> > @@ -167,8 +169,10 @@
> >
> > def __del__(self):
> > # Unlock database
> > - if hasattr(self, "lockfd"):
> > - DITrack.Util.Locking.unlock(self.lockfd)
> > + if self.lock:
> > + DITrack.Util.Locking.unlock(self.lock)
> >
>
> Why do we need to explicitly remove the lock? I think it should be
> released once the lock object is gone.
hmm.
i just tried to create correct code, which create lock and remove it
after himself.
Also it's a rudiment after attempt to create windows-specific lock.
removed in r1650
More information about the Dev
mailing list