[Rpm-maint] RFC: Unblocking of signals within rpm

Panu Matilainen pmatilai at redhat.com
Thu Jul 19 11:41:58 UTC 2007


On Thu, 19 Jul 2007, Tomas Mraz wrote:

> On Thu, 2007-07-19 at 13:30 +0300, Panu Matilainen wrote:
>> On Thu, 19 Jul 2007, Michael Schroeder wrote:
>>
>>> On Thu, Jul 19, 2007 at 12:58:29PM +0300, Panu Matilainen wrote:
>>>>
>>>> Attached patch turns the signal handling within rpmdb upside down: we no
>>>> longer run the whole damn thing with termination signals blocked with
>>>> occasional checking possibly resulting in exit() from deep within rpmlib,
>>>> but instead have an active signal handler that will mop up any open
>>>> transactions and iterators and pass on the signal to caller.
>>>
>>> Whoa, doing complex things in a signal handler is very dangerous.
>>> You can interrupt rpm deep inside some glibc function like "malloc".
>>
>> Yes, but then this is a terminating signal handler, and AFAICT does just
>> what's described in glibc manual as the cleanest way to handle this:
>> http://www.gnu.org/software/libc/manual/html_node/Termination-in-Handler.html
> But you should not in the signal handler for example call any function
> which manipulates the heap (calling free() for example).

Better ideas are most welcome.

An atexit() handler to clean up would be just perfect, except that it 
doesn't get called if the process gets terminated with a signal. Back to 
square one.

If the signal handler called exit() it'd be possible to do the cleanup in 
atexit() handler but then there's no chance to re-raise the signal to give 
API users a chance to do what they need in case of a signal (which was 
largely the point in this "excercise"). Back to square one...

 	- Panu -



More information about the Rpm-maint mailing list