Grim state of libpthread (needs serious cleanup)

Denys Vlasenko vda.linux at googlemail.com
Mon Mar 16 06:32:12 UTC 2009


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?
 
> > This quick check shows that there are many functions
> > exported which should not be.
> 
> that's because glibc uses a version script to handle exported functions while 
> we do not.
> -mike

We can hide these symbols with libpthread_hidden_proto().
While libpthreads.old uses it, libpthreads ("non-old")
do not use libpthread_hidden_proto() at all.
--
vda


More information about the uClibc mailing list