This is the mail archive of the 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

Kaz Kylheku <> writes:

> On 29 Aug 2001 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.

You don't understand what is happening here.  Nothing is changing in
pthreads, all the pthreads data structures remain the same and nothing
changes at all in the application.  Assuming I remove the __libcThr
aliases (which I agree is correct), the linuxthreads library remains
EXACTLY the same, including all the data structures.

The opaque data structures are only used inside libc, not in the
application, and they are designed so that nothing inside libc
actually uses the data, it just provides pointers to the block of data
for the threads package to use.

I also agree with Ulrich; the initializers need to be done some
other way.  This may force the other threads packages to conform to
some linuxthreads things, but that's an acceptable compromise.

However, my main question has not really been answered.  Assuming I
came up with an acceptable solution, is this something you (the glibc
maintainers) are interested in?  Do you want to be able to support
other threads packages?


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