On Jul 18, 2007, at 11:11 AM, Ralf S. Engelschall wrote:
On Wed, Jul 18, 2007, Jeff Johnson wrote:
[...]
If I read correctly, the conservative/portable approach is -
lpthread in
executable so that external libraries linked with -lpthread function
correctly. That kinda forces "mandatory" -lpthread for rpm when
external libraries may (or may not) have -lpthread.
This is for what pkg-config(1) or a foo-config(1) of the third-library
is for: that RPM doesn't have to know this or _always_ try to link
against pthreads. And for the same reason why created our rpm.pc, btw.
But this pthread mess is a general problem, yes.
Mess indeed.
[...]
The path forward is adding per-object thread locks, the path
backwards is
removing -lpthread, the status quo needs to change no matter what.
I'm always a little bit surprised that people use POSIX pthread mutex
even in non-multithreaded applications. Sure, can be done. But that it
really should be 10 times faster than some other mutex approaches I'm
sceptical about -- perhaps for one single OS, ok.
The private report of 10x performance increase was from Keith
Bostic. ;-)
The benchmark context is what is confusing: locking overhead is 10x
faster, the wall clock
continues to click along at exactly the same rate.
The real benefit is unifying process <-> thread locks to reduce the
impediment to attempting multi-threaded. Changing rpm's locking
scheme in order to pursue a surely controversial multi-threaded
rpmlib implementation Chimera Just Ain't Going To Happen.
What is the purpose of RPM locking its database operations? That no
second RPM instance (either rpm(1) or an RPM API based application)
trashes it while one RPM is already operating, right? At least for
this
one doesn't need POSIX pthread mutexes. Here an fcntl(3) based
approach
even within RPM itself should be both sufficient and fast enough...
See lib/rpmlock.c for a perfectly sane shared/exclusive lock used
(optionally
but flexibly! ;-) by rpmlib. Work done by Gustavo Niemeyer. The killer
is that there is too much flexibility in choice of the path to the fcntl
lock, and the locking scope is imperfectly specified as well. E.g.
the RedHat beehive build system used to have all rpmdb's in
all chroot's open, thereby having outer <-> inner chroot lock contention
that no path to file with a fcntl lock can ever solve. Well a fd can be
passed from parent -> child in the usal ways, let's not go there.
The confusion in rpm comes when the Berkeley DB, not the transaction
lock, is abused for rpm inter-process locking. This was a design flaw
in the original rpm implementation.
Which reminds me: the "lockdbfd" option needs to be fixed in
rpmdb/db3.c. What is there now does not honor the lock, only
warns. That was the correct behavior when rpm4 <-> legacy rpm3
applications were competing for an rpm lock, but otherwise is
entirely the wrong thing to do is "lockdbfd" is going to be abused
for rpm transaction locking purposes.
Or are you planning that RPM can be really internally run
multi-threaded? Then the case is different, of course. Then you _have_
to use POSIX pthreads, of course.
rpm is already multi-threaded many years now:
rpm -Uvh --psmthreads *.rpm
or
rpm -Uvh --fsmthreads *.rpm
The current rpm implementation is rather uselessly frozen in amber
atm, and
needs to change. I quote myself:
The path forward is adding per-object thread locks, the path
backwards is
removing -lpthread, the status quo needs to change no matter what.
73 de Jeff
______________________________________________________________________
RPM Package Manager http://rpm5.org
Developer Communication List rpm-devel@rpm5.org
