On Sat, Oct 13, 2012 at 3:00 PM, Canek Peláez Valdés <can...@gmail.com> wrote: > 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?
[snip] >> 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). You got the semantics right. (We could quibble on tradeoffs, but that's more a question of style and scenario...) (Well, I'm not certain that POSIX thinks of threads as parents to each other. That would seem silly to me, but that may be because I come to multithreaded programming from Windows, where threads belong to a process, not to each other. Your main thread could terminate, but the process would continue to exist until all threads terminated, or until ExitProcess() or TerminateProcess() were called.) > > 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). There are *numerous* IPC mechanisms available on Linux. For starters, there are sockets (domain, IPv4, IPv6, et al), named pipes, signals, mmap()'d files, messaging, etc. One IPC mechanism that's fairly common on both Windows and Linux is for two processes to mmap() a block of memory (could be 4KB, could be 40MB, whatever.) by creating an anonymous file. On Linux, this is usually done in /dev/shm/, IIRC. On Windows, you can use a physical file or one of a few different ways. When one process writes to the chunk of its address space mapped to that file, the other process can immediately see those changes. All that remains is sending the other process a signal or some other driving mechanism to wake it up and have it look at that region for updates. dbus is only a 'little wonder' in that it provides protocol constraints and language bindings, which isn't really relevant when we're talking about same-address-space vs separate-address-space threading models. > > 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. Apache has several Multi-Processing-Modules. mpm_worker spawns threads within a common process, and each thread handles a different client. mpm_prefork spawns processes, where each process handles a different client. I'm not aware of any mpm which flips between 'worker' and 'process'. Which mode the administrator chooses depends on his needs. While mpm_worker would be more efficient, almost everybody uses mpm_prefork (or the similar mpm_itk), because modules like mod_php aren't necessarily safe to run in a multithreaded fashion. (It's not necessarily the module's fault, but rather that some of the language extensions aren't written for it.) > AFAIK, Google Chrome was > the first desktop program in Linux which uses several processes > runnning under the same GUI. Absolutely not. I used to play a game called 'realtimebattle', a programming game where you programmed a robot to destroy all the competing robots. Realtimebattle would launch your program (written in whatever language you liked, as long as the kernel could launch it) as its own process and communicate with it via stdin/stdout. -- :wq
