On Tue, 3 Jul 2007, seth vidal wrote:
On Tue, 2007-07-03 at 23:25 +0300, Panu Matilainen wrote:
---
If you want ^C handling in yum the choices are (as I've told you before):
1) being careful about when the database is opened.
2) exposing the same signal bit mask to the bindings so that ^C can be
detected whenever.
Other alternatives include
3) adding infrastructure to chain signal handling out of rpmlib.
---
Yum is now in far better shape for 1) than it was before, because it
doesn't have to download tons of headers and feed into rpm for dep
resolution.
The last time we tried 1) we got blamed for corrupting the rpmdb, over
and over and over again. Your thoughts on that debacle?
Whether it caused rpmdb corruption or not I dunno, it's entirely possible
it triggered races in the locking. I don't trust the rpm locking that
much. But more to the point, re-opening the db for each and every rpmdb
access to avoid holding the db open isn't what Jeff means about "being
careful" in 1) :) More like: open it when you have to, do your business
and close it. The less you do that, the better.
Since the new depsolver, the situation would look roughly like this:
1) open+close db for checking distroverpkg
2) download metadata if necessary
3) open db, depsolve
4) if filelists needed in 3), close db, download and reopen, continue 3)
5) close the db
5) download packages
6) do the final transaction
The reopens in 4) are at max the number of enabled repositories, whereas
earlier the similar situation if was the number of packages in the
transaction and then some. A *big* difference there. I think the previous
time yum cached rpmdb header id's over those reopens which is not really
safe, if such tricks aren't done now it should be just fine to do the
above.
Then there's the extreme approach: open the rpmdb just once initially and
import the data you need into a sqlite db just like any other repodata and
then close it. With the new depsolver, you only need to open it again for
the actual transaction.
Adding proper signal handling/passing, be it 2) or 3) or whatever variant
I'm going to look into anyway.
okay - b/c if we're just in a readonly db and we get a sigterm - that's
fine.
Oh and then there's another locking related issue I just noticed when
looking at this: yum (and any related code like plugins, pirut etc)
tracebacks can leave stale rpmdb locks around. I suppose yum could insert
a global exception handler whenever a ts is active to clean up any rpmdb
accesses. I'm going to have a look at mopping up the locks on tracebacks
at bindings level anyway, and sooner than later I hope.
okay - I think that's where I'd rather see it go. That and have fewer
places where we actually need the rpmdb at all.
If it can be done in a sane way, yes. I'm not that familiar with the
Python C API (yet :) but I would assume it's possible to plant a
sys.excepthook from C when needed (rpmdb iterators open, basically) and
clean up things from there and then chain back to original excepthook.
We'll see...
- Panu -
_______________________________________________
Yum-devel mailing list
[email protected]
https://lists.dulug.duke.edu/mailman/listinfo/yum-devel
