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
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.
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.
Here was the first indication I received:
https://lists.dulug.duke.edu/pipermail/rpm-devel/2006-November/
001857.html
Here is part of the history (which goes back even further)
http://www.archivesat.com/
RPM_internals_development_and_distro_coordination/thread158194.htm
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.
hth
73 de Jeff
_______________________________________________
Rpm-list mailing list
Rpm-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/rpm-list
