At 8:59 PM -0500 12/4/06, Jeff Johnson wrote: >On Dec 4, 2006, at 8:50 PM, Tony Nelson wrote: I see you trimmed some unneeded context, good. I've been leaving it in as you probably get lots more unrelated messages to respond to than I do. >>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. OK. >>> 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. Thank you. >>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 think we are talking at cross-purposes here. I would expect that "a rpmdbCheckSignals() exit" is needed when it is RPM code that is interrupted, which won't ever happen from this Python code. >From Python code, all that could be needed is the normal unwinding that the code already does. It's no different than if the code had decided to exit for any other reason. If it's in a loop iterating over something, exit the loop as if finished, dispose of anything that would normally be disposed, exit that function, and so on. If it's downloading packages and just has a ts open that it won't be using again until it's finished, there's nothing RPM needs to (un)do, and no benefit from it suddenly quitting much later because a handled SIGINT is still set as a flag. I'm pretty sure that any time Python code can see the SIGINT flag set, RPM can not have anything open that needs a rpmdbCheckSignals() exit. I also see no harm in extremely occasionally dropping a second SIGINT onto the floor, so I don't mind introducing such a possible race condition by having two unlocked atomic ops, sigismember() then sigdelset(). SIGINT is special this way, as it normally is a request from a user. I wouldn't want to treat SIGSEGV this way. >I can/will add methods to rpm-python for any reasonable API, that's >pretty easy stuff. That would save me some work! I'll ask you when I'm prepared. I'll hack something first, and then let you do it right. :) >>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. The use case for yum having SIGINT handling is that it /isn't/ in any RPM code, so I don't think that will be needed. If I can make the whole thing automatic, so that all yum would need is to get rid of the extra closes / opens, that would probably be the easiest thing to get accepted. >Thanks for the effort. Some python-head expressing a wish for what is >needed is what has stopped me from doing the coding. You're welcome. Just asking for something is not of any use, what's needed is the effort of an acceptable patch. It just takes a while to find out what that would be. I expect it will be a couple of days before I'm back. I'll probably start a new thread on rpm-devel when I do have something. -- ____________________________________________________________________ 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
