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