Well.. i think its rather rare that common "user-land" programs would interact with kernel space threads, unless it would require kernel managed tasks or routines.
In my opinion, native threads would suffice, if programs are only designed for small specific tasks or would only constitute forking threads in user-space. Anyways, paintings and portraits are what their specific painters make them ;) It all boils down to the "need" of _someone_ or of the project. -- Xander R. Solis ----------------------- "Trust is the greatest gift one person can give another" GNUPG Key: 1024D/525 On Mon Jul 26 1:03 , Andy Sy <[EMAIL PROTECTED]> sent: >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 cant even get a LIBC that is f*cking standard across >each distros because the glibc authors cant 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 ---- Introducing Spymac MailPro: http://www.spymac.com/mailpr -- 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
