RPM Community Forums

Mailing List Message of <rpm-devel>

Re: rpmdb.c blockSignals()

From: Alexey Tourbin <at@altlinux.ru>
Date: Mon 18 Aug 2008 - 18:10:38 CEST
Message-ID: <20080818161038.GX618@altlinux.org>
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.

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


  • application/pgp-signature attachment: stored
Received on Mon Aug 18 18:11:02 2008
Driven by Jeff Johnson and the RPM project team.
Hosted by OpenPKG and Ralf S. Engelschall.
Powered by FreeBSD and OpenPKG.