On 5/19/06, Luciano Miguel Ferreira Rocha <strange@xxxxxxxxxxxxx> wrote:
On Fri, May 19, 2006 at 04:20:43PM -0400, Jeff Johnson wrote: > You are misguided. OK. I thought the lock was internal to the database backend. Sorry for the noise.
Nope. The fcntl lock insures that only one install transaction runs, database resource locking is different and handled by Berkeley DB locks.
> Spawning a child with a "sleep N" is way way hackier than removing > the lock. Why? Waiting for the current rpm to finish before starting another is what a user does.
The difference between what a "user does" and how long an asynchronous scriptlet waits before attempting to install should be obvious. There is no way to choose the N in "sleep N" accurately, any chosen value will fail to wait long enough for a sufficiently large transaction to finish. That's what is hacky. Having one process fork off another, rather unrelated, process is rather surprising and unusual as well. Meanwhile a user can see that the previous transaction has not completed before starting another operation. 73 de Jeff
_______________________________________________ Rpm-list mailing list Rpm-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/rpm-list
_______________________________________________ Rpm-list mailing list Rpm-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/rpm-list
