Over the years, I've had to explain in gory detail how thread
aware bindings can use non-thread safe rpmlib by taking
out a "Big Lock" to serialize all rpmlib uses from within bindings.

My most recent assistance is here:
     https://lists.dulug.duke.edu/pipermail/rpm-python-list/2007- 
December/000228.html

At this point its easier to insturment a "Big Lock" on the 10-30 most  
common
rpmlib methods than it is for me to explain what to do Yet Again.

Adding finer grain'ed, per-object locks is not a whole bunch more  
implementation
work.

The tedious issue with threading -- as always -- is protecting static  
variables. But what
really needs doing is refactoring all the static variables into a global
(mostly config related) structure with a RW lock.

Note that rpmpgp.c is particularly embarassing, mostly because an API
to rpmpgp.c has never been attempted, the entire crypto implemetation
in rpmio is based on a one week proof-of-concept OpenPGP parser,
and I never dreamed that RPM would become the "RPM Pubkey Manager".

The end-point of making rpmlib thread safe is to (finally!) attempt to
improve install performance by (my estimate from RHL 8.0 time frame)
between 15-25% measured by wall clock, with the major saving
coming from overlapping scriptlet execution with next package unpacking
(read: reaping status from child asynchronously).

There's undocumented --fsmthreads and --psmthreads that piut
every stage in the file/package state machines on a separate thread
for anyone who wishes to see multithreaded rpm behavior. Been there
since RHL 9 where I got side tracked into vendor peculier issues like
"multilib" and "selinux".

What say ye?

My personal opinion is that the "Big Lock" for rpmlib should be  
attempted
immediately, and that pthread lock's should be added to per-object  
data structrures,
so that deadlock issues can (at least) be looked at.

73 de Jeff