At 4:02 PM -0500 12/1/06, Jeff Johnson wrote: >On 12/1/06, James Olin Oden <james.oden@xxxxxxxxx> wrote: >> > >> > My understanding is that the changes to yum to repeatedly open and close >> > the RPM database are to work around RPM's seizing of SIGINT. I believe >> > this proposal is a cleaner, safer, and more effective workaround for that >> > issue. (More effective in that fewer SIGINTs are eaten by RPM.) >> And racy. Its not really solving the problem. In general its been my >> experience that signal handlers in libraries is a bad thing. That >> said librpm is IMO a very special library. The issue is that there >> is no way for rpm to know (today but not maybe tommorow) what the >> consumers needs are in the event of a signal. That said there should >> be no way for a consumer to know what needs to be done by librpm in >> the event a signal is caught (the particulars that is). So what do >> you do. >> >> Probably the right thing to do is provide one of two things (or both): >> >> - have librpm provide a method for a consumer to register a >> callback to be usedin the event a signal is caught (probably >> sending what signal and what rpms action will be, such as >> exiting or not). This sounds like a reasonable way to cope with RPM's justified invasive paranoia. I know that it is hard to do much in a signal handler; what Python does is defer the actual handling until task time, much as RPM does. I suppose this callback would also be called at task time, and not in the signal handler? As possible use cases: In yum, a user may press Ctl-C to get yum to give up on a sluggish mirror and move on to the next, hopefully faster, mirror. This works more or less well with different versions of yum, or Python (2.5 and 2.4.4 are good), or Fedora, and mostly depends on the possibly accidental behavior of a library module that yum uses. More hypothetically, yum and other programs start subprocesses and might also want the SIGCHLD in such cases, for reasons as good as RPM's. [ My patch to Python <http://python.org/sf/1519025>, which fixes Python's Ctl-C handling for sockets with timeouts, was accepted and ships in Python 2.5 and 2.4.4. It helps yum quite a bit in responding to Ctl-C. The rest of making Ctl-C work well during the downloading phase of yum was done in my Stablemirror yum plugin by stealing back the SIGINT signal, in a subclass of that library module. Should the user choose to exit or the KeyboardInterrupt exception somehow not be handled, yum's existing code for the purpose would handle closing the RPM database. I was content to let RPM (and yum) have its way during the actual installation phases of yum, as that seemed safest -- even if the RPM database is properly closed, with transactions either all in or all out, just having only some of a dependent set of packages installed seems like a bad idea. ] >I can add the callback if necessary, but there's a fair amount of overhead >that would be needed ... Darn. :-( I sort of thought that it would just be called from rpmdbCheckSignals(). >> - Have rpm have a single method to call in the event that the >> program is exiting. This would require rpm to internally >> track all transactions in existance in a processes, or at >> least all DB connections. > >... rpmlib is already keeping track of the list of all opened rpmdb's, >no biggie ... > >> So who is going to write the patch to really fix this problem? >> > >I am. I'll salt in checks of rpmsqCaught on exiting method exits, >and throw the keyboard exception when any of the ^C usual candidates >occur. Does this mean that when a SIGINT signal is received, rpmlib would gracefully stop whatever it was doing and then tell the application that it got a SIGINT, or that it would gracefully exit the application? Please pardon my ignorance. What happens when it is client code that is interrupted by the signal, not a call to rpmlib? It appears to me that usually rpmlib has been opened up and has set its signal handlers, and then the application does things and calls rpmlib from time to time, and that a signal can be received when application code is active, not rpmlib code. I may just not be following things. I might try to trace through it all, but my gdb-fu is not strong and tracing Python code to rpmlib code seems a bit much for me. >> In all universes your still going to have issues with SIGCHLD since >> rpm clearly needs this when running scriptlets. >> > >Sssshhh! Lest "Free the SIGCHLD!" becomes the next droning chant ... >There are already yum bug reports being dumped on rpm because scripts, >indeed, fail, with output to stderr, and so its a rpm, not a yum, problem >to deal with the messed up progress bars. Rpmlib opened up a can of worms when it stole the signals in the first place. Sure, it needs something like that in order to be robust in the face of stupidity or carelessness, but re-canning still takes a bigger can. If James' first proposal were adopted, then rpmlib clients would also get the SIGCHLD and could decide what to do about it. Note that I'm not yum's author (Seth Vidal), and I hope I haven't represented myself as such. -- ____________________________________________________________________ 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
