On Aug 18, 2008, at 3:53 AM, Alexey Tourbin wrote:
> 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
>> 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.
I don't like plumbing snakes or the Intel instruction set, but that
doesn't stop me from using either.
> 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.
Screwed? signal handling reverts to the original state is/was the
> 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.
Yes having a signal handler in a library leads to many difficulties.
I can go through the design choices again again again, but having
a means to handle state associated with using a Berkeley DB is most
A signal handler, with internal refcounts and chained state tied to
is the simplest implementation I've been able to devise.
chained signal handlers out of library into application are feasible,
assume cooperative and intelligent application developers, not going
to happen afaict, see the 4 years it took for yum to figger out how to
handle ^C e.g.
atexit et al have portability issues, and will not handle exceptional
conditions like "kill -9" and spontaneous reboots with active rpmdb.
(aside) yes not all "exceptional" events are handled gracefully,
meteor strikes within
2m of keyboard are a known problem case with the current implementation.
but sure better can be done ...
73 de Jeff
Received on Mon Aug 18 15:13:54 2008