Grim state of libpthread (needs serious cleanup)

[Mike Frysinger]

On Monday 16 March 2009 02:32:12 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

reorganization of source or style or anything along those lines is useless.  
the design of linuxthreads is pretty "hacky" compared to NPTL, but it mostly 
works.  there isnt much that can be done to improve it, especially along the 
lines of POSIX compliance since much of the problem lies with the fundamental 
design.  which is why i say that imo, any time spent on "improving" 
linuxthreads is a waste of time and harmful in the long run: it causes 
unnecessary divergence from glibc.

as for NPTL, if you wanted to look into improving that, it's actively 
maintained by glibc guys and so can see updates.  but doing so exclusively 
brings us back to one of the aforementioned issues: unnecessarily diverging 
from glibc is a very bad idea.

> * 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.

except these people dont exist.  we copy linuxthreads from upstream.  you e-
mail them and their response is "wtf do we care, use nptl".  the code added to 
linuxthreads by us is very minuscule.  mostly glue and a few fixes.

> > > 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.
>
> 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.

yes, i'm just explaining why symbols randomly showing up as exported shouldnt 
be surprising.  there are also some symbols which glibc uses but we dont 
because we dont implement all the features glibc does, or in the same way 
(stdio locking comes to mind).
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.busybox.net/pipermail/uclibc/attachments/20090316/5f6cec52/attachment-0001.pgp>