libtool-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: 1.4 release schedule [Was Re: Allowing user data in lt_dlhandles (re


From: Gary V. Vaughan
Subject: Re: 1.4 release schedule [Was Re: Allowing user data in lt_dlhandles (revisited)]
Date: Tue, 9 Jan 2001 01:13:18 +0000
User-agent: Mutt/1.2.5i

On Sun, Jan 07, 2001 at 04:16:14AM +0000, Gary V. Vaughan wrote:
> On Sun, Jan 07, 2001 at 12:54:10AM -0200, Alexandre Oliva wrote:
> > On Jan  5, 2001, "Gary V. Vaughan" <address@hidden> wrote:
> > 
> > > I have never done multi-threaded programming in anger
> > 
> > The pointers to lock functions would initially be NULL
> 
> Okay.  I'll buy it.
> 
> Do we ask the user to supply wrapper functions to our pointers,
> or should I be setting up prototypes with particular footprints?
> 
> How about:
> 
>     void (*lt_dlmutex_lock)    LT_PARAMS((void)) = 0;
>     void (*lt_dlmuxtex_unlock) LT_PARAMS((void)) = 0;
> 
> Is that sufficient?

Actually, no, it isn't.  I just started to make the changes, and the
locking needs to be done outside of the function calls.  Foe example,
the first function definition in libltdl/ltdl.c:

  int
  lt_dladderror (diagnostic)
       const char *diagnostic;
  {
    intindex= errorcode - LT_ERROR_MAX;
    const char  **temp    = 0;
       
    temp = LT_DLREALLOC (const char *, user_error_strings, 1 + index);
    if (temp == 0)
      {
        last_error = LT_DLSTRERROR (NO_MEMORY);
        return -1;
      }
    else
     {
        user_error_strings = temp;
     }
                                               
    user_error_strings[index] = diagnostic;

    return errorcode++;
  }
  
This function might try to set last_error to indicate an out of memory
condition in one thread, but before that thread calls lt_dlerror() to
see what went wrong, some other thread may have set last_error to
something else entirely.  Putting a mutex around the assignment to
last_error in this case is not enough.

How is this interaction handled with libc functions?  Would you just
assume that errno is useless in multi-threaded applications?  Or is
the programmer responsible for mutex locking before any call that
might set errno, and then copying the contents of errno before
unlocking?  Is atomicity a goal in itself?  Or is there more to being
MT safe?

Since I am part way through, I'll submit a provisional patch shortly
-- but it will still require libltdl clients to do their own mutex
locking between API calls that might set an error (i.e. nearly all of
them) and getting the error message back with lt_dlerror().  Somehow
that feels very wrong =(O|

Cheers,
        Gary.
-- 
  ___              _   ___   __              _         mailto: address@hidden
 / __|__ _ _ ___ _| | / / | / /_ _ _  _ __ _| |_  __ _ ___       address@hidden 
| (_ / _` | '_|// / |/ /| |/ / _` | || / _` | ' \/ _` | _ \
 \___\__,_|_|\_, /|___(_)___/\__,_|\_,_\__, |_||_\__,_|//_/
home page:  /___/                      /___/                  gpg public key:
http://www.oranda.demon.co.uk           http://www.oranda.demon.co.uk/key.asc



reply via email to

[Prev in Thread] Current Thread [Next in Thread]