On Sat, Aug 16, 2008 at 05:57:30AM -0400, Jeff Johnson wrote:
> 
> 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  
> intent.
> In fact, I'd much rather have better engineering than risk aversion in  
> RPM.
> 
> 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

I think this is wrong -- with this change, blockSignals() now does
NOT block signals.  Note that e.g. db->put is neither atomic nor
reenterable (possibly cannot even close db if db->put is in progress).

However, I do not quite understand what rpmsq does.

> responsiveness might be improved. Note that how often the
> received signal mask is polled, not how long ^C is blocked,
> ultimately determines "responsiveness".