Re: 1.4 release schedule [Was Re: Allowing user data in lt_dlhandles (revisited)]

[Alexandre Oliva]

On Jan  7, 2001, "Gary V. Vaughan" <address@hidden> wrote:

> How about:

>     void (*lt_dlmutex_lock)    LT_PARAMS((void)) = 0;
>     void (*lt_dlmuxtex_unlock) LT_PARAMS((void)) = 0;

> Is that sufficient?

Yep.  Generically, one would add a void* argument, but I don't think
this is necessary.  Since this is supposed to be a global mutex,
it's ok to have it as a static variable in the module that implements
the lock and unlock functions.

However, it now occurs to me that we might want to not have these
variables registered, but, instead, to have a function to register
them, and prevent them from being modified while the lock is held.
Something like this, but using LT_PARAMS and maybe with some error
checking:

static void (*lt_dlmutex_lock)() = 0;
static void (*lt_dlmutex_unlock)() = 0;

void
lt_dlregister_lock_unlock(void (*lock)(), void (*unlock)()) {
  void (*old_unlock)() = lt_dlmutex_unlock;

  if (lt_dlmutex_lock)
    (*lt_dlmutex_lock)();
  lt_dlmutex_lock = lock;
  lt_dlmutex_unlock = unlock;
  if (old_unlock)
    (*old_unlock)();
}

There's still a small probability of problem in case two threads call
tl_dlregister_lock_unlock concurrently.  I don't see any way to avoid
this problem, though.

Some error-checking to ensure that either both lock and unlock are
non-NULL, or both are, would probably be a good thing.

>> I mean to always call rpl_[[snip]]realloc internally

> I get it now.  Will do.

Thanks, Gary!  I wish I had more time to help you with libtool :-(

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  address@hidden, redhat.com}
CS PhD student at IC-Unicamp        address@hidden, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me