This is the mail archive of the libc-alpha@sources.redhat.com mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Allowing multiple threads packages, a new threads package


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]