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