At 12:37 AM -0500 12/4/06, 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. You may well be right about how it's being used, but the TransactionWrapper class /says/ its purpose is to allow easy instrumentation of rpm.Transaction. It appears to be the "owner" of one of them, which it takes pains to close when it goes away. (If it really "owns" a TransactionSet when it returns it to use as an iterator.) (There's also a global ts which isn't being used for anything?) If it is being (mis)used to do what you say, that would be by the code that holds a reference to it choosing to forget that reference. Or are you saying that "del ts" would not do the ts.CloseDB()? I'm assuming that it would close it, which makes the destructor unnecessary. >Which was higher performing in some yum version, I still can't find >Panu's measurements though. That's OK, I accept that already (I also see Panu's reply). I read (somewhere) that performance suffers quite a bit with the new opens / closes, but that an earlier yum that had more of them was even slower. >There are other means to throw an exception on a signal. Well, yes. ;) Umm, I will look for the ones you prefer. -- ____________________________________________________________________ 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
