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

[Alexandre Oliva]

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

> How is this interaction handled with libc functions?  Would you just
> assume that errno is useless in multi-threaded applications?

It's generally implemented as a per-thread variable.  With
-D_REENTRANT, errno is generally a macro that calls a function that
returns the per-thread errno.

But that's just because errno is so pervasive in libc.  For other
functions that used to use static storage, a new reentrant function
was introduced, with the `_r' suffix, that takes a pointer to the
static storage to be used.  We may want to do this, or just suggest
the user to arrange for the unlock function to store the value of
lt_dlerror in per-thread storage.  But then, programs would have to
have some means to obtain that value.  Maybe this function should be
registered along with lock() and unlock(), and we should arrange for
lt_dlerror() to call that function, if non-NULL?  Then, unlock() would
take as an argument the error code it should register in a per-thread
variable, and geterr() would be supposed to return the value last
given to unlock() in that thread.

> Or is the programmer responsible for mutex locking before any call
> that might set errno, and then copying the contents of errno before
> unlocking?

This means locks would have to be reentrant, otherwise a thread would
deadlock with itself.

-- 
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