On Mon, 4 Dec 2006, Jeff Johnson wrote:
On Dec 3, 2006, at 11:12 PM, Tony Nelson wrote:
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?
The intent of
ts.CloseDB() # <-- this is unnecessary btw
del ts
is to keep rpm from "stealing" signal handlers, on last
rpmdb close the original signal handlers are lazily restored.
I have heard no other reason for the "del ts" change, transaction.py
used to have a persistent transaction which kept an rpmdb
open as long as needed.
Which was higher performing in some yum version, I still can't find
Panu's measurements though.
Here's the timing info (by Terje Rosten, not me):
https://lists.dulug.duke.edu/pipermail/yum-devel/2006-November/002870.html
- Panu -
_______________________________________________
Rpm-list mailing list
Rpm-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/rpm-list
