On Thu, Sep 05, 2002 at 08:18:40PM +0000, Charles Hannum wrote:

 > Had you bothered to *look* at the FreeBSD code, or *ask* how it works,
 > rather than simply tossing out another strawman, you would know that
 > the code does not actually introduce a significant penalty for
 > non-threaded apps.  It uses a callback (dllockinit()) to enable
 > locking.

Actually, I have read their code quite carefully (because I've already
been thinking about this issue for the nathanw_sa branch).  Apparently,
you have not, because if you look at revision 1.46 of their rtld.c, you
will find the following log message:

revision 1.46
date: 2000/07/08 04:10:30;  author: jdp;  state: Exp;  lines: +135 -115
Solve the dynamic linker's problems with multithreaded programs once
and for all (I hope).  Packages such as wine, JDK, and linuxthreads
should no longer have any problems with re-entering the dynamic
linker.
.
.
.
The dllockinit() interface is now deprecated.  It still exists,
but only as a do-nothing stub.  I plan to remove it as soon as is
reasonably possible.  (From the very beginning it was clearly
labeled as experimental and subject to change.)  As far as I know,
only the linuxthreads port uses dllockinit().  This interface turned
out to have several problems.  As one example, when the dynamic
.
.
.

...and if you read the code for that function:

/*  
 * This function is deprecated and has no effect.
 */ 
void
dllockinit(void *context,
           void *(*lock_create)(void *context),
           void (*rlock_acquire)(void *lock),
           void (*wlock_acquire)(void *lock),
           void (*lock_release)(void *lock),
           void (*lock_destroy)(void *lock),
           void (*context_destroy)(void *context)) 
{  
    static void *cur_context;
    static void (*cur_context_destroy)(void *);
  
    /* Just destroy the context from the previous call, if necessary. */
    if (cur_context_destroy != NULL)
        cur_context_destroy(cur_context);
    cur_context = context; 
    cur_context_destroy = context_destroy;
}

-- 
        -- Jason R. Thorpe <thorpej@wasabisystems.com>