[ditrack commit] r1617 - src/trunk/DITrack/DB

[Ivan Glushkov]

Hmm. Interesting. Really. The destructor shouldn't call!
But i changed the Database.__del__() methods (added pdb.set_trace):

     def __del__(self):
         # Unlock database
         #if hasattr(self, "lockfd"):
         pdb.set_trace()
         DITrack.Util.Locking.unlock(self.lockfd)

Then run program with a link to nonexistant directory as dbroot.
As you can see it does call __del__!!! I've got trace:

$ ./dt -d nonexinstant ls
'nonexinstant' (specified in command line) doesn't exist or is not a  
directory
> /home/gli/ditrack/src/trunk/DITrack/DB/Common.py(173)__del__()
-> DITrack.Util.Locking.unlock(self.lockfd)
(Pdb) bt
   /home/gli/ditrack/src/trunk/dt(218)?()
-> globals.command_table.dispatch(opts)
   /home/gli/ditrack/src/trunk/dt(73)dispatch()
-> self.table[opts.fixed[0]].run(opts, globals)
   /home/gli/ditrack/src/trunk/DITrack/Command/list.py(48)run()
-> db = DITrack.Util.common.open_db(globals, opts)
   /home/gli/ditrack/src/trunk/DITrack/Util/common.py(76)open_db()
-> err("'" + dbroot + "' (" + source + ") doesn't exist or is not a "
> /home/gli/ditrack/src/trunk/DITrack/DB/Common.py(173)__del__()
-> DITrack.Util.Locking.unlock(self.lockfd)

Try on bsd! Will it be the same?
I don't yet understand, what's happened.


On Mon, 21 May 2007 00:31:06 +0400, Vlad Skvortsov <vss at 73rus.com> wrote:

> Ivan Glushkov wrote:
>> Hi.
>> I haven't understood you.
>>> What is the possible scenario that would render "lockfd" unbound?
>> Does it mean "when we have uninitialized self.lockfd"?
>
> Yes.
>
>> Now it may become uninitilized if Database.__init__() failes
>> (reasons:
>>             raise DITrack.DB.Exceptions.NotDirectoryError
>>             raise DITrack.DB.Exceptions.NotDatabaseError
>>             raise DITrack.DB.Exceptions.InvalidVersionError
>> )
>
> But if the database constructor fails (raises an exception), there is no  
> database object. So, the destructor is never called.
>
>
>>
>> To tell the truth, the purpose of this commit was to enable moving  
>> lock/unlock functions to separate module.
>> It was impossible without slight modification of the current  
>> functionality.
>> It will be entirely rewritten in the nearest future. ;)
>
> Ok.
>
> [skipped]
>