Xander Solis wrote:
Sounds like blabbering to me :) Well.. programming is hard for programmers who don't think for a moment, plan and design before diving into coding, as it is life is hard for people who live their life with no sort of plan at all :)
my 2 cents worth...
The main complaint is that there is no *official* release of glibc which has NPTL and as such NPTL support cannot be considered to be there yet. Like the guy says 'We can’t even get a LIBC that is f*cking standard across each distros because the glibc authors can’t be bothered to do releases' (and it has been more than a year - or is it 2 years+ ? - since the last release).
Of course Ulrich Drepper, the glibc maintainer, has another take on the matter which is basically stop your whining if you don't want to do anything about it yourself =D. The problem here is Ulrich is working for RedHat and one can always subscribe to the conspiracy theory that it is in RedHat's interest to delay the release of an official glibc (one that need not be patched) because they got NPTL working on a 'patched to h*ll glibc' on their distro...
Still, considering the problems that abound on the latest versions of Redhat (many seemingly pointing to the use of NPTL as the culprit), I guess there's a good reason for not releasing an official NPTL-capable glibc yet...
If you're not interested in using the pthreads API (which a lot of people say sucks anyway - it's main redeeming quality being the fact that it is a POSIX standard that presumably works identically across different *nix platforms) NPTL provides, you can in theory muck around with the Linux-specific clone() system call and do your own user-thread/process to kernel-thread mapping.
It's got to be kernel improvements (like the O(1) scheduler and futexes) and not NPTL per se that's ultimately responsible for the huge scalability boost in 2.6, so I'm wondering if fork() can't also be rewritten to make use of these new kernel enhancements. Keep in mind that the pthreads API is supposed to map terribly to Linux's kernel thread mechanisms and is why it takes a hell of a lot of magic for NPTL to work the way it does...
Another thing to realize is that if you're not that concerned about using mapped-to and scheduled-by kernel threads because, for example, you're not using an SMP machine, you can always use whatever cool threading/concurrency mechanism you have (like for example, Stackless Python's tasklets/channels) in lieu of pthreads.
Not using kernel-scheduled / kernel-mapped threads in no way implies a performance hit. For example, Stackless author Christian Tismer claims 1,000,000(!) tasklets scalability on a low end Athlon machine ( see http://www.stackless.com/pipermail/stackless/2002-February/000341.html ) which certainly blows NPTL away. For now, these are in all likelihood being mapped to a single kernel thread (whether on NT or Linux) so it won't be able to take advantage of SMP.
-- reply to: a n d y @ n e t f x p h . c o m -- Philippine Linux Users' Group (PLUG) Mailing List [EMAIL PROTECTED] (#PLUG @ irc.free.net.ph) Official Website: http://plug.linux.org.ph Searchable Archives: http://marc.free.net.ph . To leave, go to http://lists.q-linux.com/mailman/listinfo/plug . Are you a Linux newbie? To join the newbie list, go to http://lists.q-linux.com/mailman/listinfo/ph-linux-newbie
