Allowing multiple threads packages, a new threads package

[minyard at acm dot org]

I have done some modifications to glibc to allow different threads
packages to be used and have them interact properly with glibc.  I
also have a threads package I am working on.

I would LOVE to hear from some glibc maintainers about this.  I have
posted this earlier and send direct mails, and I haven't heard
anything back.  Even if you hate my guts, I'd at least like to know so
I can stop bugging you :-).

The patches and the threads package are at
  http://sourceforge.net/projects/ssthreads/
I have been using them for a while on an x86 and PowerPC system and
they seem stable.

Why do I think we need this?  I don't think one threads package can
meet the needs of all applications.  Some applications need raw
performance and very lightweight operation, others need real-time
guarantees, others need strong safety and coherency even in the
presense of faults.  So glibc needs to be able to support multiple
external threads packages.

I could theoretically supply the current interface (the __pthread_xxx
calls in bits/libc-lock.h), but it's pthread specific and it makes
assumptions about the size of a mutex and condition that I can't live
by (mine are bigger).  Plus, it uses static initializers, which won't
match up with my stuff.

I'm not saying that my approach is the best or even the right way, but
I would like to have the right way put into glibc.

-Corey