How goes the NPTL merge?

Carmelo AMOROSO carmelo.amoroso at st.com
Tue Mar 31 07:40:31 UTC 2009


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Denys Vlasenko wrote:
> 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.
> 
exactly !

>>> (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.
> 
I would like to have the code integrated before.

> 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".
I have no time for this, and prefer to read something already
available, instead od producing something for dummies.
> --
> vda
cheers,
carmelo
> _______________________________________________
> uClibc mailing list
> uClibc at uclibc.org
> http://lists.busybox.net/mailman/listinfo/uclibc
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAknRyO8ACgkQoRq/3BrK1s8G8ACdFqQKd95ga31b5JJhA/NX5v0j
SEYAoNrdLo/IPyozH5JPMok0XLoBobMC
=Pq+i
-----END PGP SIGNATURE-----


More information about the uClibc mailing list