Grim state of libpthread (needs serious cleanup)

[Bernhard Reutner-Fischer]

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.