On Mon, Sep 29, 2008 at 06:26:26PM -0700, Khem Raj wrote: >On Mon, Sep 29, 2008 at 9:04 AM, Bernhard Reutner-Fischer ><[EMAIL PROTECTED]> wrote: >> On Mon, Sep 29, 2008 at 02:36:32PM +0200, Hans-Christian Egtvedt wrote: >>>On Sat, 27 Sep 2008 16:57:20 -0500 >>>Rob Landley <[EMAIL PROTECTED]> wrote: >>> >>>> I'd like to apply the following small patch as a start on at least >>>> deprecating the hell out of LINUXTHREADS_OLD. All it does is stop it >>>> showing up in menuconfig, and make the symbol default to n. >>>> >>>> We really do need to get down to one pthreads implementation before >>>> we start adding nptl-threads, and getting the new we have a better >>>> chance of maintaining actually widely tested is an important part of >>>> that. >>>> >>>> Comments? >>>> >>> >>>It will remove threads support for AVR32 architecture, so I would say >>>no to apply it. >>> >>>I agree that we should aim for all architectures to have NPTL, but only >>>after all the architectures actually are working with this thread >>>library IMHO. >> >> agree. >> Rob, if you want to deprecate linuxthreads.old after the 0.9.30 release >> then please go to the NPTL branch and add support for i386, powerpc, >> m68k etc, etc either against nptl or linuxthreads.new. > >LT old is stable and has been used over the years. IMO before we >depricate it we should make sure that LT.new works on all platforms. I >dont know how much testing LT.new has received so far. In my >experience whenever I tried it on mips or arm it would not compile. >May be going with .30 as it is and then deprecating it would get .30 >release out faster in future may be we would directly transition to >NPTL and wont need LT.new at all.
Jumping up and down threads is completely pointless ATM. The start of 0.9.31 will be the proper time to get excited about threads, for now adding or removing a particular thread impl is OT. Rob, Any help in fixing a bug from mantis in either thread impl is welcome. If you think that neither of these 2 impls is worth your time, then go to the nptl branch and help there, please. thanks for your support :) _______________________________________________ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
