On Sat, Oct 13, 2012 at 1:40 PM, Mark Knecht <markkne...@gmail.com> wrote: > On Sat, Oct 13, 2012 at 11:16 AM, Canek Peláez Valdés <can...@gmail.com> > wrote: >> On Sat, Oct 13, 2012 at 12:10 PM, Mark Knecht <markkne...@gmail.com> wrote: >>> On Sat, Oct 13, 2012 at 9:15 AM, Canek Peláez Valdés <can...@gmail.com> >>> wrote: >>> <SNIP> >>>> >>>> We can only know seeing the code. Timur, this is the little test I >>>> made which creates 5 threads and runs them for 1 minute. In my case, >>>> `ps x` shows only 1 PID, care to give it a try? >>>> >>>> ---------------------- >>>> #include <pthread.h> <<====== >>>> #include <unistd.h> >>>> #include <stdlib.h> >>>> #include <stdio.h> >>> >>> Thanks for the test case. Like you I see only one thread. However the >>> test case wouldn't compile for me without the -pthread option so it >>> makes me wonder what happens to a program like I had pointed to >>> yesterday that uses the old style threading that did create lots of >>> process ids? Possibly an nptl system would still generate lots of ids >>> for that program and that's what he's seeing? >>> >>> Just curious. I don't program but I'm always sort of interested. >> >> You got your answer. NTPL stands for Native POSIX Thread *Library*. As >> it name says, it is a library (with support in the kernel and in >> glibc). If you don't use the library (-lpthread), you cannot make use >> of its advantages. >> >> What "old style threading" did you use for your test case? >> >> Regards. >> -- >> Canek Peláez Valdés >> Posgrado en Ciencia e Ingeniería de la Computación >> Universidad Nacional Autónoma de México >> > > As for 'old style' I only meant code that did threads but didn't use > the POSIX libraries. (I guess...) > > Actually I hadn't run the test case at the time but was referring to > the one I pointed the OP at yesterday: > > http://www.makelinux.net/alp/032 > > However it's essentially the same as yours (not as elegant, but > functionally similar). However the results shown on that page show > different pids for the threads. When I run that same code here I get > the same pids: > > mark@c2stable ~ $ ./pthread2 > main thread pid is 5387 > child thread pid is 5387 > ^C > mark@c2stable ~ $ > > Now, this does make me curious about some things running on my system. > Two for instance, Google Chrome and akonadi_agent, have LOTS of pids. > I was assuming those were different threads and were demonstrating > what the OP was asking about, but now I'm not so sure. How does a > single program on an nptl system generate all these different pids?
Because Google Chrome is actually LOTS of programs. I don't know about akonadi (don't use KDE), but Chrome doesn't use threads; it uses different process for each tab (and for several plugins, I believe), and it integrates all those process in a single GUI using come kind of IPC. The idea is that if a tab crashes (bad pulgin, rogue JavaScript, etc.), it only crashes the tab, not the whole browser. It saves us from the nightmare that forced us to "killall -9 mozilla" from time to time some years ago. A thread is a "lightweight process"; it has its own call stack, but it shares the same memory space as its "parent" (actually, the thread that created it). The advantages are many: since all threads in the same process share the same memory space, they can easily and quickly communicate between each other. The tradeoff is that if one thread crashes, the whole program does (AFAIK, someone please correct me if I'm wrong). A process has its own call stack and its own memory space; and while it can share file descriptors with its parent (the process where it was created), including pipes, it cannot easily and quickly communicate with a process different from its parent (hence little wonders like dbus, whose job is precisely to provice Inter Process Communication [IPC] between different processes). For threads in Linux/Unix you usually use POSIX threads, although there are alternatives. For processes you use fork; everytime you use "ls" or "cp" in a terminal, or launch a program using KDE or GNOME, your shell or desktops forks a new process for it. Up until very recently most programs used threads to do several things at once; some years ago apache started to do a "hybrid" approach, where it forks or launches threads dependign on the load of the system, other server programs followed it. AFAIK, Google Chrome was the first desktop program in Linux which uses several processes runnning under the same GUI. Regards. -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
