RPM Community Forums

Mailing List Message of <rpm-devel>

Re: rpmdb.c blockSignals()

From: Jeff Johnson <n3npq@mac.com>
Date: Sat 16 Aug 2008 - 11:57:30 CEST
Message-id: <1C419D60-9FBE-43CB-B6AA-822FF37B3651@mac.com>

On Aug 16, 2008, at 4:12 AM, Jeff Johnson wrote:

> Please do not change anything with blockSignals.

Hmmm, I've neglected to supply sufficient details, and so
it sounds like I'm forbidding better engineering. That was not my  
In fact, I'd much rather have better engineering than risk aversion in  

So let's say this patch is attempted:

@@ -822,7 +822,7 @@ static int blockSignals(/*@unused@*/ rpm
      (void) sigdelset(&newMask, SIGHUP);
      (void) sigdelset(&newMask, SIGTERM);
      (void) sigdelset(&newMask, SIGPIPE);
-    return sigprocmask(SIG_BLOCK, &newMask, NULL);
+    return sigprocmask(SIG_SETMASK, &newMask, NULL);


The net result is that rpm would run without blocking any
of those explicitly mentioned signals, and ^C et al would be handled
sooner. There are certain long running loops like rpm -qa whose
responsiveness might be improved. Note that how often the
received signal mask is polled, not how long ^C is blocked,
ultimately determines "responsiveness".

The existing librpmdb signal handler (when instantiated) will handle
all those signals just fine, setting the bits sooner rather than later.
And if the librpmdb signal handler is not instantiated, then its up to
applications to do whatever with their signal handlers.

One risk factor with  the patch above is EINTR returned on certain  
system calls.
AFAIK, that is handled by rpmio correctly. There are a few places where
rpmio is not used consistently, but the main code paths through rpm  
always use rpmio. But there may be some loops that are not expecting  
reads/writes that will need to be fixed.

There are some issues with signal delivery to threads that may appear.  
that the hard issue of catching and delivering SIGCHLD when all rpm  
are being run on an ap[plication thread is already handled, that's  
what all
the insanity with pthread_mutex() and pipe(2) serialization is  

So if you want, make the above change, and let's find out what else  
needs to be done.

Note that there needs to be a way at runtime to revert rp[m behavior  
to last known good
implementation in case some issue is found after release, but that's  
just adding a macro.

Does that sound like a more positive suggestion?

73 de Jeff
Received on Sat Aug 16 11:57:36 2008
Driven by Jeff Johnson and the RPM project team.
Hosted by OpenPKG and Ralf S. Engelschall.
Powered by FreeBSD and OpenPKG.