More whining re glibc from

http://www.tenslashsix.com/index.php (2004-06-30 blog entry)

"The fact of the matter is this is a result of basically one
thing: glibc folks deciding that releases aren’t worth while
and that distros should just take snapshots at their leisure.
People talk about linux not being a good target becomes it’s
hard to target, compared to win32, and they couldn’t be more
right. 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. I’ve heard that they will be back to making releases
again soon. I can only hope this is the case. Regardless the
big guys are gonna have a patched to h*ll glibc, so it’s not
like it’s gonna matter."


But here's the question, why can't fork(), which makes use of the same clone() system call that NPTL ultimately does, not be able to scale up just as dramatically as the much-hyped, yet maddeningly unavailable, NPTL. After all:

1. It is not the /RedHat-hostaged/ glibc's pthreads implementation
   that is giving us these threads by the tens of thousands
   scalability, it's the *kernel* (as in Linux and not GNU), correct?
   Pthreads' API is generally seen as being as horrible and full of
   compromises anyway.  See
   http://www-124.ibm.com/pthreads/ and digest the discussion at
   http://www.kerneltraffic.org/kernel-traffic/kt20000911_84.html#1

2. "Threads are evil."  http://threading.2038bug.com/index.html

3. Normal processes on Linux are far less heavyweight
   vis-a-vis threads as they were on Unix.  From
   http://www-106.ibm.com/developerworks/library/l-sc5.html :

   "In many, many situations, the best way to multi-task an
   application is to decompose it into collaborating /processes/
   rather than /threads/. Programmers commonly resist this reality.
   One reason is history: processes used to be far "heavier" than
   threads, and, under most flavors of Windows, still are. With modern
   Linux, though, a context switch between distinct processes might
   take only 15% more time than the corresponding context switch between
   same-process threads. What you gain for that cost in time is a *far
   better understood and more robust programming model*. Many
   programmers can safely write independent processes. Relatively few
   are safe with threads."


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

Reply via email to