Re: Allowing multiple threads packages, a new threads package

[minyard at acm dot org]

Ulrich Drepper <drepper@redhat.com> writes:

> minyard@acm.org writes:
> 
> > Thanks for the reply.  I'll do as you describe, although the patch is
> > over 1100 lines long, I hope that's ok.
> 
> Far too much.

Sorry, I originally put it on a website and pointed to it, but I was
told that wasn't the way to do things.  I should have done what I
thought was right and not followed instructions.

> There is absolutely no reason to introduce these __libcThr names.  The
> names we use now are fine and don't have to be changed.  Adding yet
> more names means adding runtime overhead due to name lookup,
> relocations etc.

I agree.  It's bad to pollute the namespace.

> Also, replacing initialized mutexes with uninitialized plus explicit
> initialization is completely unacceptable.  No way this gets in.

This was also a big concern of mine, I didn't like using this either.
It especially makes the dynamic linking mutex wierd.  But I couldn't
come up with a better option.

> Also, these opaque struct definitions look very suspicious.  I'm not
> sure this won't create compatibility problems and there is no reason
> at all to make the structures bigger than necessary for any one
> implementation.

I don't like this either, but I don't think it's a big concern because
it only affects mutexes used inside libc (not application mutexes),
and there's not a huge number of these, from what I can tell.  I don't
see how it could create compatibility problems.

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

> In any case, this is no material for glibc 2.2.x.

That's fine, and I'm not saying this is the right way, or when it has
to be done, this was just a strawman.  So do you have any interest in
supporting a generic interface where multiple threads package can work
with glibc?  I guess that's my real question.

Thanks,

-Corey