Retiring from uClibc development

[Rich Felker]

On Tue, Apr 11, 2006 at 09:44:27PM +0100, Paul Brook wrote:
> On Tuesday 11 April 2006 20:45, Rich Felker wrote:
> > On Tue, Apr 11, 2006 at 01:53:59PM -0400, Mike Frysinger wrote:
> > > On Tuesday 11 April 2006 13:45, Jan-Benedict Glaw wrote:
> > > > (Is there some kind of documentation available what needs to be
> > > > supported in binutils and GCC for NPTL and TLS?)
> > >
> > > first worry about TLS, then worry about NPTL
> >
> > I would encourage you to not support but reject TLS. It's an ugly,
> > bloated, nonstandard extension to the language and its propagation
> > into user programs should be discouraged as much as possible.
> 
> What do you suggest as an alternative? AFAICS NPTL (which implies TLS support) 

An approach like NPTL does not imply TLS, at least not what Drepper
means by TLS. All of this thread-local stuff can be internal to the
implementation or just use conventional methods.

> in the only realistic option if you're serious about thread support.

I've spent a good bit of time looking at the POSIX docs and basically
there is no realistic option if you're serious about POSIX threads.
The API is horribly misdesigned, full of "features" that cannot be
implemented efficiently on top of the C language and which conflict
with the design philosophy of the C language. All the options require
one or more of the following:

- GNU/GCC/ELF/Linux-specific hacks.
- Significant bloat and code duplication for thread/nonthread cases.
- Unacceptably bad performance for normal non-threaded apps.
- Complicated relocation issues.

If anyone has ideas for how to implement pthreads without all these
problems I'm eagar to hear. But I won't be holding my breath.
Drepper's solutions are part of his whole job-security-thru-obscurity
scheme and I'm not interested in them..

Rich