How goes the NPTL merge?

Mike Frysinger vapier at gentoo.org
Mon Mar 16 06:35:57 UTC 2009


On Wednesday 25 February 2009 06:49:09 Denys Vlasenko wrote:
> On Tuesday 17 February 2009 09:16:01 am Carmelo AMOROSO wrote:
> > Rob Landley wrote:
> > > Just noticed Denys checking more stuff into the nptl branch. 
> > > (Mirroring a commit to mainline with a second commit to the branch.)
> >
> > Basiacally Denys is tryuing to make the merge easier doing this double
> > commit when working on generic stuff (not tls neither nptl related)
> >
> > > How much is left to
> > > merge into mainline from there?
> >
> > I'm trying to create, as explained times ago, single patches
> > for TLS/futexes/NPTL part for step by step inclusion into the trunk,
>
> As of now, uClibc-nptl source tree is 2.4 megabytes bigger than
> uClibc trunk. This is suspiciously big, 20...25% growth, why?

that's awful

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

> (2) Some people will object to having "int oldtype" not
> at the beginning of the block. This is C++ism.
> Even though I am not one of them, I would prefer
> to not alienate that group.

it isnt a C++ism (well, anymore).  it's a C99ism.  i personally prefer it as 
it can easily lead to cleaner and less buggy code.

> (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).
-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/f86e67ed/attachment.pgp>


More information about the uClibc mailing list