Comment 6 for bug 633668

(In reply to comment #4)
> Lockes are used to serialize changes. The corollary to choosing
> locks that magically evaporate on abnormal (like kill -9) termination
> is that whatever inconsistencies/serialization MUST be dealt with.

My proposal is that readers should take a fcntl read lock without modifying the rpmdb and writers should take an fcntl write lock in addition to modifying the rpmdb as they currently do. fcntl will enforce serialization, and the modification made by writers will ensure that the rpmdb is flagged as inconsistent after a writer terminates abnormally. The rpmdb is not inconsistent after a reader terminates abnormally.

> The existence (or "stale lock" cleanup on process termination) is hardly
> the issue.

It is in this bug! Of course, maintaining proper serialization and recovery is the most important concern, and my proposal does that.

> "Use fcntl locks!" is hardly a panacea; in fact its a useless piece of FUD.

It's (the new element of) the solution for this bug.