Re: SUG: Automatic RPM database verification and repair

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On Dec 4, 2006, at 8:50 PM, Tony Nelson wrote:


And I'm saying further that (by my reading of Transaction.py) the whole
destructor (__del__(self): self.close()) is unnecessary and pointless,
since whenever it would be called, ts would have been released and closed
itself normally without it.


;-) Perhaps. Even though I rewrote most of rpm-python, I'm a C, not a python,
programmer.

Meanwhile, the eventual bestest fix is going to be to handle
signals through other means and making the ts object more
persistent (thereby preserving the database environment's
concurrency guarantee of "multiple readers or single writer",
and being higher performing as well.

Got that?

Yes. It's what I'm working toward. Note that I have no influence over yum
other than to work up a patch and then argue for it.


Very cool.

At the moment, I can't find how to get the currently received signals from rpmlib. I only see two places where rpmsqCaught is used, in rpmsqAction() where they're set, and rpmdbCheckSignals(), where they're read. I don't see an available funciton that just polls them, though rpmsqCaught is a
global and such a thing could be added.  Was the suggestion that
rpmsqCaught could be used to make such a polling function?


Yes, rpmsqCaught is the bit mask of received signals, and a rpmdbCheckSignals() exit is what is needed to gracefully close cursors and databases, thereby freeing
locks.

I can/will add methods to rpm-python for any reasonable API, that's pretty easy stuff.

Once I have a polling routing, it looks like either sprinkle such polling into yum, or use a Python threading.Timer() to poll a couple of times a second (started automatically by the rpm Python package). (That would poll
from a different thread.  My understanding is that sigismember() and
sigdelset() are safe across threads and CPUs.)

Sprinkling into existing rpm-python method exits may be needed if yum resists
changing.

Thanks for the effort. Some python-head expressing a wish for what is needed
is what has stopped me from doing the coding.

73 de Jeff

_______________________________________________
Rpm-list mailing list
Rpm-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/rpm-list

[Index of Archives]     [RPM Ecosystem]     [Linux Kernel]     [Red Hat Install]     [PAM]     [Red Hat Watch]     [Red Hat Development]     [Red Hat]     [Gimp]     [Yosemite News]     [IETF Discussion]

  Powered by Linux