Allowing multiple threads packages, a new threads package

[minyard@acm.org]

Ulrich Drepper <drepper@redhat.com> writes:
> libio is used outside the libc in libstdc++.  And the "there's not a
> huge number" argument doesn't fly with me.  This is source-level
> configuration and this means there is no need to be sub-optimal.
> 
> > I don't understand, this won't affect the code generated when using
> > linuxthreads at all.
> 
> Your patch of course changes the code generation.  The explicit
> initialization, the increased structure size, additional names.

I still don't understand.  If you can't change any code generated,
then you can't change much in glibc.  I agree that the initialization
and additional names is a problem, and I can fix those (although I
assume you want to be able to change those things in other glibc
changes).

This is fully backwards compatible with previous implementations, it
doesn't change pthreads at all, and it doesn't change any application
generated code all.  It only changes the size of the data structures
used inside glibc.  And the old libio would continue work (unless you
were using a new threads package with a larger mutex, cond, etc.).
When recompiled, libio will continue to work because it (wisely) uses
an opaque pointer to the _IO_lock_t structure.

But you still haven't answered my main question, which is: Is the
glibc community interested in supporting multiple threads packages?

-Corey