On Wed, May 11, 2011 at 12:23 AM, Rich Felker <[email protected]> wrote: > On Tue, May 10, 2011 at 07:57:12PM +0100, Will Newton wrote: >> >>https://bugs.uclibc.org/2089 >> > >> > This is supposed to work just fine with NPTL. >> >> So is support for linuxthreads dropped with this release? It seems a >> shame when people are willing to support it. > > I hope so. Aside from pthread, is there any libc feature where an old, > broken-by-design version is intentionally kept around and supported? > Do we need an alternate stdio implementation where data in the buffers > sometimes gets written or read twice under certain conditions? Do we > need an alternate regex implementation that mixes up \(\) and ()? Do > we need an alternate malloc that sometimes reserves too little memory > and gives you heap corruption? > > LinuxThreads is *that* *broken*. Sure you could write a program using > malloc that works around fatal bugs in malloc or a program using stdio > that works around fatal bugs in stdio, but would you really want to > put that out in a production environment? Why the same logic doesn't > apply to threads is beyond me....
Well no, it isn't that broken. It was the default threading implementation on Linux for many years and has shipped in millions of devices that continue to work to this day, so from a POSIX lawyers point of view it may be broken but from a practical point of view it's a useful feature. Not all embedded architectures have full support for NPTL/TLS yet. _______________________________________________ uClibc mailing list [email protected] http://lists.busybox.net/mailman/listinfo/uclibc
