Re: Allowing multiple threads packages, a new threads package

[Ulrich Drepper <drepper at redhat dot com>]

minyard@acm.org writes:

> > Far too much.
> 
> Sorry, I originally put it on a website and pointed to it,

I means there were too many changes.

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

If the thread library you want to use cannot provide this you should
reconsider.  This is absolutely no justification to penalize those
implementations which provide this needed feature.  In the worst case
you'll have to check whether the mutex is initialized in every locking
call.

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

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.

-- 
---------------.                          ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \    ,-------------------'   \  Sunnyvale, CA 94089 USA
Red Hat          `--' drepper at redhat.com   `------------------------