On Sat, Aug 16, 2008 at 12:12:13PM -0400, Jeff Johnson wrote:
> >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).
> Correct, signals are not blocked, they are caught by the rpmsq
> handler, with the patch applied. Assuming the code is still correct.
> No exit is undertaken until the caught signal mask is tested. db->put
> is still atomic, and no re-entry is undertaken.
> >However, I do not quite understand what rpmsq does.
> SQ == Signal Queue.
> rpmsq registers, catches and delivers signals.
Oh, I see now. I don't like rpmsq then.
Consider that you open two rpmdb databases simultaneously.
Signal handling is screwed, and after you close them both,
rpmsq handler is still installed, and "oact" is lost.
Actually, if we consider rpmdb a *library*, rpmsq is bad idea.
A library must not intervene signal handling, it may only only block
signals for a short period of time to perform its critical sections.
However, from the "library" point of view, there is no change
to shut down rpmdb gracefully, and rpmdbRock is then useless.
Received on Mon Aug 18 09:53:54 2008
- application/pgp-signature attachment: stored