At 4:41 PM -0500 12/3/06, Jeff Johnson wrote: >On Dec 3, 2006, at 3:49 PM, Tony Nelson wrote: > >> >> >>Umm, in order to help me when I try to read yum to understand what it is >>doing, are you saying that yum is copying some data from RPM and then >>assuming that it will not change across unlocking / relocking the >>database? That is, it uses possibly stale data, but not invalid >>iterators? And please pardon my ignorance of BerkelyDB; I will work to >>learn about it. >> > >This code from yum/rpmUtils/transaction.py is what all the fuss is about Thank you for pointing me to the offending part of yum. It will help me focus on the problem, and possibly come up with a solution acceptable to yum's developers. >1.24 (mjs 03-Sep-06): self.open = True >1.24 (mjs 03-Sep-06): >1.24 (mjs 03-Sep-06): def __del__(self): >1.24 (mjs 03-Sep-06): # Automatically close the >rpm transaction when the reference is lost >1.24 (mjs 03-Sep-06): self.close() >1.24 (mjs 03-Sep-06): >1.24 (mjs 03-Sep-06): def close(self): >1.24 (mjs 03-Sep-06): if self.open: >1.24 (mjs 03-Sep-06): self.ts.closeDB() >1.24 (mjs 03-Sep-06): self.ts = None >1.24 (mjs 03-Sep-06): self.open = False > >That overloads a transaction object with a lazy open/close >of an rpmdb in order to handle ^C. Destructors are really hard to get right in Python, because if there is a reference loop the garbage collector zaps the objects in it in arbitrary order. This one looks OK on the surface, as it only releases a resource, but I'll look harder. I'd actually have expected the TransactionSet would already do this on its own when it's last reference disappeared; I'll look at its code later. >While I think the code is insanely clever, and I'm quite pleased >that rpm is surviving as well as it is in spite of unanticipated >and bizzarre uses of the implementation, the code is solving >entirely the wrong problem, and triggering a lot of instability. I don't quite see that this code is a problem. It only runs at task time (not at signal time), when the object is being reclaimed by the Python interpreter. It should be like any other call to close the database. It can't happen inside a call to rpmlib (unless there is more than one thread). Am I misunderstanding the issue? >Here was the first indication I received: > https://lists.dulug.duke.edu/pipermail/rpm-devel/2006-November/ >001857.html I've read this thread; I will try to understand it better with time. >Here is part of the history (which goes back even further) > > http://www.archivesat.com/ >RPM_internals_development_and_distro_coordination/thread158194.htm OK. >And there is another recent post by Panu (which I can't find, from >11/2006) identifying the overloading as a cause of worse performance in >yum (even though the claim is faster!). > >The slowdown is rather easy to understand, repoening a Berkeley DB is >not exactly a cheap operation. AIUI, yum does that less often now than did the version in FC6 test releases, and Yum's developers realize that it is a trigger for the problem. Whether or not it is a bug in RPM or BerkelyDB or yum that is being triggered, it is not necessary to do it, or even particularly helpful in order to get SIGINT to work usefully. I hope to develop a solution that is acceptable to RPM and to Yum. We'll see what I manage. >hth I think it does, thanks. -- ____________________________________________________________________ TonyN.:' The Great Writ <mailto:tonynelson@xxxxxxxxxxxxxxxxx> ' is no more. <http://www.georgeanelson.com/> _______________________________________________ Rpm-list mailing list Rpm-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/rpm-list
