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
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
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