Thread-safe RPC library

[Eric Norum]

I've modified the RPC library to make it thread-safe as needed by an
application I'm working with (Experimental Physics and Industrial
Control System -- http://www.aps.anl.gov/epics/).  Is there any interest
in folding the changes back into the glibc distribution?  Here are some
notes from the README describing what I did:

Design Goals
============
1. Existing single-threaded applications which dynamically link the
   RPC routines must continue to operate.
   100%
   Applications which accesses the RPC routines through the documented
API
   operate as they did before.

2. Existing single-threaded applications must be able to use the RPC
   headers and libraries with no changes to the application source code.
   100%
   Source code which accesses the RPC routines through the documented
API
   will compile without change.

3. No performance impact on existing applications.
   95%
   There is a small performance penalty for single-threaded
applications.
   Access to all global and static variables within the RPC library now
   involves a function call and one level of indirection.

4. No application changes to use the thread-safe RPC routines.
   100%
   Each pthread can use the RPC/XDR calls as if it were the only thread
   in the application.

5. No performance impact on multi-threaded applications.
   90%
   Multi-threaded applications suffer the same small performance
penalty.
   Access to all global and static variables within RPC now involves
   a function call, a call to pthread_getspecific, and one level of
   indirection.
   One POSIX thread-specific variable is used to hold a pointer to the
   RPC thread-specific data.

-- 
Eric Norum                                 address@hidden
Department of Electrical Engineering       Phone: (306) 966-5394
University of Saskatchewan                 FAX:   (306) 966-5407
Saskatoon, Canada.