Hi, Rob Landley a écrit :
>> IIRC >> there have been some issues in the past... so, unless we are totally >> sure, we need to keep the working/stable and old linuxthreads.old. > > No, what we do is we keep the 0.9.29 tarball around and if people have bugs > trying to use 0.9.30 they _report_ them to us. If they want to use the old > threading code, they can use the old version of the library. If they want > the new features, then they help us find (and fix) the new bugs. > You mean adding in the 0.9.30 untested code ? Do you know if linuxthreads pass some thread regression tests (glibc one, ltp, ...) ? >> Remeber that, even when merged, NPTL is available only for 3 archs at >> the time being. > > Who said anything about NPTL? Right now, in 0.9.29, there's LINUXTHREADS_OLD > and there's a second implementation of Linuxthreads that most people haven't > been testing because they're still on LINUXTHREADS_OLD. There's not much > point in having two of these right now, and adding NPTL would make _three_. > I'd like to keep it to no more than two, which means I need to yank one > before NPTL goes in. I remember than 1 year ago, developers agree to drop LINUXTHREADS, because work should be done on nptl instead trying to fix LINUXTHREADS. [1] And I agree with that. If nptl merge happen soon there no point to do some extra work on LINUXTHREADS. Matthieu PS : if only companies "selling" uclibc could hire some developers to improve the mainstream version ... [1] nptl is really missing on some arch to get faster thread switch, some mutex with prio inversion, ... _______________________________________________ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
