How goes the NPTL merge?

[Denys Vlasenko]

On Monday 16 March 2009 07:35, Mike Frysinger wrote:
> > I must admit that what I am seeing in not particularly encouraging.
> > My fear is that yet another pthread implementation will land,
> > without cleanup, without docs, with many hacks scattered
> > all across the tree.
> 
> meh, that's just how pthreads "works".  if we want to keep leeching off of 
> glibc, there isnt too much we can (or should) do in the nptl code base.

I can't say that I like this idea. The idea behind uclibc, I think,
is to make "saner than glibc" libc. It means cleanups, cleanups, cleanups.
(An example: did you see what glibc does with SIGCNLD in nanosleep?)

OTOH, I understand that maybe we just lack developers dedicated
to cleaning up, and maintaining it that way, of libpthread. Pity.

> > (3) Why some aliases are using __foo instead of __libc_foo? Foe example,
> > __writev, __clone. Can you make it uniform?
> 
> probably warts from glibc, leading up to the next part:
> 
> > (4) Since glibc 2.8 manages to NOT create any __libc_accept or __accept,
> > can you avoid it too? Which leads to mey next comment...
> 
> that's because glibc has moved cancellation handling to inside of each 
> cancellation end point.  uClibc is doing things the way glibc used to: weak 
> symbols.
> 
> > (5) Can you create some rudimentary documentation about NPTL internals
> > and put it into docs/*? I do not understand what this "cancellation" stuff
> > is all about and why we need to bend over backwards to support it.
> > I imagine there is a very good reason for it, but "imagine" and
> > "understand" are two different things. Docs will really help here.
> > If you want them proof-read and discussed, the mailing list is the best
> > place.
> 
> the POSIX docs explain cancellation.  it's a pure pthread concept and has no 
> bearing when threads are disabled.  see like pthread_cancel(3).

I would like to have a more informal doc.

Imagine what C++ standard says about virtual functions
- very formal language, nothing about their impelmentation,
harder to read, doesn't help as much as informal doc
which says how virtual function tables work, where are they placed,
why it was done this way, etc.

IOW: I do not think we need "what does POSIX say about cancellation" doc,
we need "cancellation for dummies and how we implement it in uclibc".
--
vda