On Wednesday 25 March 2009 06:10:01 Bernhard Reutner-Fischer wrote: > On Mon, Mar 16, 2009 at 07:32:12AM +0100, Denys Vlasenko wrote: > >On Monday 16 March 2009 06:17, Mike Frysinger wrote: > >> On Sunday 15 March 2009 22:55:56 Denys Vlasenko wrote: > >> > I am going to add this script to docs/* in hope to at least > >> > start some cleanup work. Libpthread (any of its three flavors > >> > we have) is poorly documented and looks too complex. > >> > >> "too complex" is an opinion :p. attempting to "clean up" linuxthreads > >> beyond anything cursory is a waste of time and likely to result in > >> unnoticed regressions. > > > >That's why I did not start frenzily patching it, and brought up > >the issue on the list. > > > >There are several things I can do, all have pros and cons: > > > >* Start improving it myself > > Pros: something will be done > > Cons: I can break libpthreads since I am not an active user of it > > > >* Send mails with veiled (or blunt) accusations that whoever worked on > > libpthreads did a bad job. > > Pros: nothing will break (more than it is broken now) > > Cons: nothing will likely be materially fixed, time will be wasted > > in flamewars and I will likely get a few developers antagonized. > > > >Which road do you think I should take? > > I think that improving NPTL would be a good thing, i suppose that > we ultimately want to abandon the other impls in favour of it, at > least mid- or long-term.
i dont think so. keeping one linuxthreads alive and "functional" isnt hard. ignoring the 2.4 vs 2.6 debate (and ignoring that i still see people running 2.2 on some ports), NPTL implies TLS which simply doesnt exist for some ports. and while you can say "x86 has been fully vetted with TLS/NPTL/2.6", that is certainly not the case with all ports, and certainly not nearly as long. -mike
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ uClibc mailing list [email protected] http://lists.busybox.net/mailman/listinfo/uclibc
