-----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 > [email protected] > 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----- _______________________________________________ uClibc mailing list [email protected] http://lists.busybox.net/mailman/listinfo/uclibc
