1 |
On Sat, Oct 13, 2012 at 3:00 PM, Canek Peláez Valdés <caneko@×××××.com> wrote: |
2 |
> On Sat, Oct 13, 2012 at 1:40 PM, Mark Knecht <markknecht@×××××.com> wrote: |
3 |
>> On Sat, Oct 13, 2012 at 11:16 AM, Canek Peláez Valdés <caneko@×××××.com> wrote: |
4 |
>>> On Sat, Oct 13, 2012 at 12:10 PM, Mark Knecht <markknecht@×××××.com> wrote: |
5 |
>>>> On Sat, Oct 13, 2012 at 9:15 AM, Canek Peláez Valdés <caneko@×××××.com> wrote: |
6 |
>>>> <SNIP> |
7 |
>>>>> |
8 |
>>>>> We can only know seeing the code. Timur, this is the little test I |
9 |
>>>>> made which creates 5 threads and runs them for 1 minute. In my case, |
10 |
>>>>> `ps x` shows only 1 PID, care to give it a try? |
11 |
|
12 |
[snip] |
13 |
|
14 |
>> Now, this does make me curious about some things running on my system. |
15 |
>> Two for instance, Google Chrome and akonadi_agent, have LOTS of pids. |
16 |
>> I was assuming those were different threads and were demonstrating |
17 |
>> what the OP was asking about, but now I'm not so sure. How does a |
18 |
>> single program on an nptl system generate all these different pids? |
19 |
> |
20 |
> Because Google Chrome is actually LOTS of programs. I don't know about |
21 |
> akonadi (don't use KDE), but Chrome doesn't use threads; it uses |
22 |
> different process for each tab (and for several plugins, I believe), |
23 |
> and it integrates all those process in a single GUI using come kind of |
24 |
> IPC. |
25 |
> |
26 |
> The idea is that if a tab crashes (bad pulgin, rogue JavaScript, |
27 |
> etc.), it only crashes the tab, not the whole browser. It saves us |
28 |
> from the nightmare that forced us to "killall -9 mozilla" from time to |
29 |
> time some years ago. |
30 |
> |
31 |
> A thread is a "lightweight process"; it has its own call stack, but it |
32 |
> shares the same memory space as its "parent" (actually, the thread |
33 |
> that created it). The advantages are many: since all threads in the |
34 |
> same process share the same memory space, they can easily and quickly |
35 |
> communicate between each other. The tradeoff is that if one thread |
36 |
> crashes, the whole program does (AFAIK, someone please correct me if |
37 |
> I'm wrong). |
38 |
|
39 |
You got the semantics right. (We could quibble on tradeoffs, but |
40 |
that's more a question of style and scenario...) |
41 |
|
42 |
(Well, I'm not certain that POSIX thinks of threads as parents to each |
43 |
other. That would seem silly to me, but that may be because I come to |
44 |
multithreaded programming from Windows, where threads belong to a |
45 |
process, not to each other. Your main thread could terminate, but the |
46 |
process would continue to exist until all threads terminated, or until |
47 |
ExitProcess() or TerminateProcess() were called.) |
48 |
|
49 |
> |
50 |
> A process has its own call stack and its own memory space; and while |
51 |
> it can share file descriptors with its parent (the process where it |
52 |
> was created), including pipes, it cannot easily and quickly |
53 |
> communicate with a process different from its parent (hence little |
54 |
> wonders like dbus, whose job is precisely to provice Inter Process |
55 |
> Communication [IPC] between different processes). |
56 |
|
57 |
There are *numerous* IPC mechanisms available on Linux. For starters, |
58 |
there are sockets (domain, IPv4, IPv6, et al), named pipes, signals, |
59 |
mmap()'d files, messaging, etc. |
60 |
|
61 |
One IPC mechanism that's fairly common on both Windows and Linux is |
62 |
for two processes to mmap() a block of memory (could be 4KB, could be |
63 |
40MB, whatever.) by creating an anonymous file. On Linux, this is |
64 |
usually done in /dev/shm/, IIRC. On Windows, you can use a physical |
65 |
file or one of a few different ways. |
66 |
|
67 |
When one process writes to the chunk of its address space mapped to |
68 |
that file, the other process can immediately see those changes. All |
69 |
that remains is sending the other process a signal or some other |
70 |
driving mechanism to wake it up and have it look at that region for |
71 |
updates. |
72 |
|
73 |
dbus is only a 'little wonder' in that it provides protocol |
74 |
constraints and language bindings, which isn't really relevant when |
75 |
we're talking about same-address-space vs separate-address-space |
76 |
threading models. |
77 |
|
78 |
> |
79 |
> For threads in Linux/Unix you usually use POSIX threads, although |
80 |
> there are alternatives. For processes you use fork; everytime you use |
81 |
> "ls" or "cp" in a terminal, or launch a program using KDE or GNOME, |
82 |
> your shell or desktops forks a new process for it. |
83 |
> |
84 |
> Up until very recently most programs used threads to do several things |
85 |
> at once; some years ago apache started to do a "hybrid" approach, |
86 |
> where it forks or launches threads dependign on the load of the |
87 |
> system, other server programs followed it. |
88 |
|
89 |
Apache has several Multi-Processing-Modules. |
90 |
|
91 |
mpm_worker spawns threads within a common process, and each thread |
92 |
handles a different client. |
93 |
mpm_prefork spawns processes, where each process handles a different client. |
94 |
|
95 |
I'm not aware of any mpm which flips between 'worker' and 'process'. |
96 |
Which mode the administrator chooses depends on his needs. While |
97 |
mpm_worker would be more efficient, almost everybody uses mpm_prefork |
98 |
(or the similar mpm_itk), because modules like mod_php aren't |
99 |
necessarily safe to run in a multithreaded fashion. (It's not |
100 |
necessarily the module's fault, but rather that some of the language |
101 |
extensions aren't written for it.) |
102 |
|
103 |
> AFAIK, Google Chrome was |
104 |
> the first desktop program in Linux which uses several processes |
105 |
> runnning under the same GUI. |
106 |
|
107 |
Absolutely not. I used to play a game called 'realtimebattle', a |
108 |
programming game where you programmed a robot to destroy all the |
109 |
competing robots. Realtimebattle would launch your program (written in |
110 |
whatever language you liked, as long as the kernel could launch it) as |
111 |
its own process and communicate with it via stdin/stdout. |
112 |
|
113 |
-- |
114 |
:wq |