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.
> [...]
> 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.
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...
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.
Ralf S. Engelschall
[EMAIL PROTECTED]
www.engelschall.com
______________________________________________________________________
RPM Package Manager http://rpm5.org
Developer Communication List rpm-devel@rpm5.org
