RPM Community Forums

Mailing List Message of <rpm-devel>

Re: rpmdb.c blockSignals()

From: Jeff Johnson <n3npq@mac.com>
Date: Mon 18 Aug 2008 - 18:25:02 CEST
Message-id: <24A087D2-0198-40AD-8961-E7998378AA6D@mac.com>

On Aug 18, 2008, at 12:10 PM, Alexey Tourbin wrote:

> On Mon, Aug 18, 2008 at 09:13:14AM -0400, Jeff Johnson wrote:
>>> 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
>> intent.
>
> When you call rpmdbOpen twice (without calling rpmdbClose before the
> second time), rpmsqEnable will be called twice, and the original state
> gets lost.
>
> Okay, I know how to fix this.
>

Thanks!

>>> 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
>> definitely MUSTHAVE.
>
> Ideailly, only blocking signals for critical sections (which is
> dbiPut+dbiSync) should be enough.  If Berkeley DB was not shut
> down gracefully, it might require only minor repair (e.g. removing
> stale locks), which can be performed automatically.


There's no such thing as "minor repair" wrto rpmdb in my experience.

The next execution of rpm5 should clean up any rpmdb mess  
automagically, yes.
But then there's rpm.org <-> rpm5.org sharing /var/lib/rpm, which has  
(at least for
me) large political consequences.

Otherwise I'd agree entirely.

73 de Jeff
Received on Mon Aug 18 18:25:42 2008
Driven by Jeff Johnson and the RPM project team.
Hosted by OpenPKG and Ralf S. Engelschall.
Powered by FreeBSD and OpenPKG.