This is the mail archive of the
libc-alpha@sources.redhat.com
mailing list for the glibc project.
Re: Allowing multiple threads packages, a new threads package
- To: <minyard at acm dot org>
- Subject: Re: Allowing multiple threads packages, a new threads package
- From: Kaz Kylheku <kaz at ashi dot footprints dot net>
- Date: Wed, 29 Aug 2001 21:44:53 -0700 (PDT)
- cc: Ulrich Drepper <drepper at cygnus dot com>, Roland McGrath <roland at frob dot com>, <libc-alpha at sources dot redhat dot com>
On 29 Aug 2001 minyard@acm.org wrote:
> > In short, a change to this thread library integration mustn't change
> > the code generated when using linuxthreads (or cthreads for Hurd).
>
> I don't understand, this won't affect the code generated when using
> linuxthreads at all. It only affects stuff inside libc, and really
> only affects the size of the structures and how they are initialized.
> I have a lot of programs compiled with linuxthreads (before the patch)
> and they work fine afterwards. Backwards compatability is a must, of
> course.
The various thread-related objects are often used in a context where
the client code provides storage for them. How can something that was
compiled with pthread_mutex_t, say, work with some other mutex that has
a different size? If the new mutex is larger, the new library will
access beyond the storage provided by the client, unless it makes
special provisions for LinuxThreads clients, like provide alternate
functions.
Also, applications can statically initialize some of these objects,
like
static pthread_mutex_t = PTHREAD_MUTEX_INITIALIZER;
if I compile this, will the replacement library treat this as a valid,
correctly initialized mutex? Hmm.