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. On a vaguely related note (to your docs script) i was thinking about adding some facility to check exported functionality per config knob. i.e. build up lists of functions exported by a config symbol (e.g. for UCLIBC_HAS_OBSOLETE_BSD_SIGNAL: sigset, sighold, sigrelse, sigignore) and complain loudly after final linking if either - required stuff is not externally visible - additional symbols are externally visible I didn't yet find the time to tackle this, so if anybody has time to propose something to that effect then this would be very welcome. _______________________________________________ uClibc mailing list [email protected] http://lists.busybox.net/mailman/listinfo/uclibc
