On Sat, Oct 13, 2012 at 12:10 PM, Mark Knecht <markknecht@gmail.com> wrote:
> On Sat, Oct 13, 2012 at 9:15 AM, Canek Peláez Valdés <caneko@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

On Sat, Oct 13, 2012 at 11:16 AM, Canek Peláez Valdés <caneko@gmail.com> wrote:
> On Sat, Oct 13, 2012 at 12:10 PM, Mark Knecht <markknecht@gmail.com> wrote:
>> On Sat, Oct 13, 2012 at 9:15 AM, Canek Peláez Valdés <caneko@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?

Thanks,
Mark

On 10/13/2012 02:40 PM, Mark Knecht wrote:

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

If I'm not mistaken, Chrome breaks out different tabs into different
processes (which you can see if you open "View Background Pages" from
the menu). I can't say anything about akonadi_agent, though.

>
> Thanks,
> Mark
>

On Sat, Oct 13, 2012 at 1:40 PM, Mark Knecht <markknecht@gmail.com> wrote:
> On Sat, Oct 13, 2012 at 11:16 AM, Canek Peláez Valdés <caneko@gmail.com> wrote:
>> On Sat, Oct 13, 2012 at 12:10 PM, Mark Knecht <markknecht@gmail.com> wrote:
>>> On Sat, Oct 13, 2012 at 9:15 AM, Canek Peláez Valdés <caneko@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


Sat Oct 13 21:30:01 2012
Return-Path: <packaging-bounces@lists.fedoraproject.org>
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on
eagle542.startdedicated.com
X-Spam-Level:
X-Spam-Status: No, score=-4.3 required=5.0 tests=DKIM_ADSP_CUSTOM_MED,
DKIM_SIGNED,FREEMAIL_FROM,RCVD_IN_DNSWL_MED,RP_MAT CHES_RCVD,SPF_PASS,
T_DKIM_INVALID autolearn=ham version=3.3.2
X-Original-To: tom@linux-archive.org
Delivered-To: tom-linux-archive.org@eagle542.startdedicated.com
Received: from bastion.fedoraproject.org (bastion01.fedoraproject.org [209.132.181.2])
by eagle542.startdedicated.com (Postfix) with ESMTP id 795D520E007D
for <tom@linux-archive.org>; Sat, 13 Oct 2012 21:09:32 +0200 (CEST)
Received: from lists.fedoraproject.org (collab03.vpn.fedoraproject.org [192.168.1.70])
by bastion01.phx2.fedoraproject.org (Postfix) with ESMTP id BA42D20BDC;
Sat, 13 Oct 2012 19:09:31 +0000 (UTC)
Received: from collab03.fedoraproject.org (localhost [127.0.0.1])
by lists.fedoraproject.org (Postfix) with ESMTP id 847D540769;
Sat, 13 Oct 2012 19:09:31 +0000 (UTC)
X-Original-To: packaging@lists.fedoraproject.org
Delivered-To: packaging@lists.fedoraproject.org
Received: from smtp-mm02.fedoraproject.org (smtp-mm02.fedoraproject.org
[66.35.62.164])
by lists.fedoraproject.org (Postfix) with ESMTP id 7F8C93FDDD
for <packaging@lists.fedoraproject.org>;
Sat, 13 Oct 2012 19:09:30 +0000 (UTC)
Received: from mail-ee0-f45.google.com (mail-ee0-f45.google.com [74.125.83.45])
by smtp-mm02.fedoraproject.org (Postfix) with ESMTP id 137E43FD19
for <packaging@lists.fedoraproject.org>;
Sat, 13 Oct 2012 19:09:29 +0000 (UTC)
Received: by mail-ee0-f45.google.com with SMTP id b47so2504311eek.32
for <packaging@lists.fedoraproject.org>;
Sat, 13 Oct 2012 12:09:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s 120113;
h=message-id:date:from:user-agent:mime-version:to:cc:subject
:content-type:content-transfer-encoding;
bh=tCq9dOEstIdsLpgMVN2UxVjXzXz5xJX5Rge6PCTHdFE=;
b=uTsL99FHGerEpQhxUHC3Y4Ywl/fNLXHxZehq5ChnKHXt8tzaNQWKQCQwNCci0q4eHQ
/2w48EPiaJ6uj6PsV6jrvMLhUKEyioiLycEif9w+4eTkvG2IYbo zIlDUckkN9zIj4wWs
CJLerYtxeTjEq7nwOJjXuWPgxNQxmJwcEXcT+ezZhpX1b+h1Xq W2NeRJSg2Kb4yccxZu
28mFuCREens5pOa8LezJRId1AMIL21ni9Bp8JEO1Qha8k5ruJS Sn/FHTtyAUAK7kyxT9
RVB34m3XSygwqJ7/cdQYx0ndbLV7AVCYR+oieEo26QlzqsCqm6Nm3yT2qgZaiMaQE3 vP
Ca8Q=Received: by 10.14.213.201 with SMTP id a49mr10808343eep.4.1350155369258;
Sat, 13 Oct 2012 12:09:29 -0700 (PDT)
Received: from [192.168.2.103] (p508CBB2E.dip.t-dialin.net. [80.140.187.46])
by mx.google.com with ESMTPS id b44sm13255774eep.12.2012.10.13.12.09.27
(version=SSLv3 cipher=OTHER); Sat, 13 Oct 2012 12:09:28 -0700 (PDT)
Message-ID: <5079BCA0.6060001@gmail.com>
Date: Sat, 13 Oct 2012 21:10:24 +0200
From: =?ISO-8859-15?Q?Mario_Bl�ermann? <mario.blaettermann@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
rv:15.0) Gecko/20120911 Thunderbird/15.0.1
MIME-Version: 1.0
To: packaging@lists.fedoraproject.org
Cc: rbean@redhat.com
Subject: [Fedora-packaging] Rules for obsoleting or conflicting packages
X-BeenThere: packaging@lists.fedoraproject.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: Discussion of RPM packaging standards and practices for Fedora
<packaging@lists.fedoraproject.org>
List-Id: Discussion of RPM packaging standards and practices for Fedora
<packaging.lists.fedoraproject.org>
List-Unsubscribe: <https://admin.fedoraproject.org/mailman/options/packaging>,
<mailtoackaging-request@lists.fedoraproject.org?subject=unsubscrib e>
List-Archive: <http://lists.fedoraproject.org/pipermail/packaging/>
List-Post: <mailtoackaging@lists.fedoraproject.org>
List-Help: <mailtoackaging-request@lists.fedoraproject.org?subject=help>
List-Subscribe: <https://admin.fedoraproject.org/mailman/listinfo/packaging>,
<mailtoackaging-request@lists.fedoraproject.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: packaging-bounces@lists.fedoraproject.org
Errors-To: packaging-bounces@lists.fedoraproject.org

SGkgYWxsLAoKSSdtIGN1cnJlbnRseSByZXZpZXdpbmcgdGhlIG ZvbGxvd2luZyBwYWNrYWdlOgpo
dHRwczovL2J1Z3ppbGxhLnJlZGhhdC5jb20vc2hvd19idWcuY2 dpP2lkPTg2NTUzNQoKVGhlIHBh
Y2thZ2UgcHl0aG9uLWRhdGFub21tZXItbW9kZWxzIHNlZW1zIH RvIGJlIGEgc3BsaXRvdXQgZnJv
bQpkYXRhbm9tbWVyLCB0aGF0J3Mgd2h5IHdlIGhhdmUgY3Vycm VudGx5OgoKQ29uZmxpY3RzOiAg
ICAgIGRhdGFub21tZXIgPCAwLjIuMAoKSW4gbXkgbWluZCwgaX Qgc2hvdWxkIGJlICJPYnNvbGV0
ZXMiIGluc3RlYWQgb2YgIkNvbmZsaWN0cyIgYmVjYXVzZSBpdA ppcyB0aGUgc3VjY2Vzc29yIG9m
IGRhdGFub21tZXIuIEJ1dCB3ZSBoYXZlIGEgc29tZXdoYXQgbW 9yZSBkaWZmaWN1bHQKc2NlbmFy
aW8gaGVyZS4gVGhlIHBhY2thZ2VyIHdyaXRlczoKCiJSZWdhcm RpbmcgdGhlIENvbmZsaWN0cy9P
YnNvbGV0ZXMvUHJvdmlkZXMsIEknZCBsaWtlIHRvIHN0aWxsIG 1haW50YWluCnRoZSBkYXRhbm9t
bWVyIHBhY2thZ2UgaXRzZWxmIGFzIGEga2luZCBvZiBtZXRhLX BhY2thZ2UgdGhhdCBpbnN0YWxs
cwp0aGUgc3BsaXRvZmZzIGJ1dCBhbHNvIGluY2x1ZGVzICJmZW Rtc2ctaHViIiB3aGljaCB3aWxs
IHR1cm4gb24gYSBuZXcKc2VydmljZS4gIE9uY2UgdGhlc2UgcG Fja2FnZXMgYXJlIGFwcHJvdmVk
LCBJIHdvdWxkIGJ1bXAgdGhlIGRhdGFub21tZXIKbWV0YSBwYW NrYWdlIGZyb20gMC4xLjggdG8g
MC4yLjAgdG8gbWF0Y2ggdGhlbS4iCgpDb3VsZCB3ZSBzcGxpdC BvdXQgdGhlIGFwcHJvcHJpYXRl
IGZpbGVzIGZyb20gZGF0YW5vbW1tZXIgaW5zdGVhZCwKdGhyb3 dpbmcgYXdheSB0aGUgbmV3IHJl
dmlldyByZXF1ZXN0PyBNZWFucywgd2UgaGF2ZSBhICJkYXRhbm 9tbWVyIiBiYXNlCnBhY2thZ2Ug
d2hpY2ggaXMgYSBtZXRhcGFja2FnZSBvbmx5IHdpdGggc29tZS Bjb21tb24gZmlsZXMsIHdoaWNo
IHB1bGxzCnRoZSBuZWVkZWQgZGVwZW5kZW5jaWVzLiBBbnkgaW RlYXMgZm9yIGEgY29udmVuaWVu
dCBzb2x1dGlvbiB3aGlsZQprZWVwaW5nIGEgcHJvcGVyIHVwZ3 JhZGUgcGF0aD8KCkJlc3QgUmVn
YXJkcywKTWFyaW8KLS0KcGFja2FnaW5nIG1haWxpbmcgbGlzdA pwYWNrYWdpbmdAbGlzdHMuZmVk
b3JhcHJvamVjdC5vcmcKaHR0cHM6Ly9hZG1pbi5mZWRvcmFwcm 9qZWN0Lm9yZy9tYWlsbWFuL2xp
c3RpbmZvL3BhY2thZ2luZw=

On Sat, Oct 13, 2012 at 3:00 PM, Canek Peláez Valdés <caneko@gmail.com> wrote:
> On Sat, Oct 13, 2012 at 1:40 PM, Mark Knecht <markknecht@gmail.com> wrote:
>> On Sat, Oct 13, 2012 at 11:16 AM, Canek Peláez Valdés <caneko@gmail.com> wrote:
>>> On Sat, Oct 13, 2012 at 12:10 PM, Mark Knecht <markknecht@gmail.com> wrote:
>>>> On Sat, Oct 13, 2012 at 9:15 AM, Canek Peláez Valdés <caneko@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

On 10/13/12 19:15, Canek Peláez Valdés wrote:
> 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?

I have re-read all messages and I noticed Canek writing about the 'ps x'
output. I was using htop to watch what's happening. When I used 'ps x',
I indeed saw just a single process. Looked around google for the
difference between the two, and sure enough, htop by default shows all
threads in a process, but ps does not. You have to supply special flags
to ps to have it show the threads.

So I started focusing on the pid's that htop is showing for my simple
app's threads. When I try to locate them under /proc/<...>, they don't
exist. Further search in google and indeed, the pid's shown for threads
aren't really "process id's" in the traditional sense and there is no
folder under /proc for them. My app has pid 12397 and one of the threads
has pid 12404. To look up the thread pid, one needs to look under
/proc/12397/task/12404.

So, mystery (for me) solved. Thanks for all the replies!

--
Timur

On Sat, Oct 13, 2012 at 2:50 PM, Michael Mol <mikemol@gmail.com> wrote:
[snip]
> (Well, I'm not certain that POSIX thinks of threads as parents to each other.

Hence the reason I put "parent" in quotes, and I specified "actually,
the thread that created it".

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

Yeah, none of them "easy and quickly" to use, or at least not if you
compare it with shared memory.

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

Yup, certainly neither "easy" nor "quick".

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

You right, of course; it has nothing to do with the discussion at
hand. Is just that I *really* like dbus, and I preferred it over
almost any other IPC mechanism in Linux.

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

OK, I will rephrase it: Google Chrome is the first *relevant* 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

On Sat, 13 Oct 2012 23:13:31 +0300
Timur Aydin <ta@taydin.org> wrote:

> On 10/13/12 19:15, Canek Peláez Valdés wrote:
> > 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?
>
> I have re-read all messages and I noticed Canek writing about the 'ps
> x' output. I was using htop to watch what's happening. When I used
> 'ps x', I indeed saw just a single process. Looked around google for
> the difference between the two, and sure enough, htop by default
> shows all threads in a process, but ps does not. You have to supply
> special flags to ps to have it show the threads.
>
> So I started focusing on the pid's that htop is showing for my simple
> app's threads. When I try to locate them under /proc/<...>, they don't
> exist. Further search in google and indeed, the pid's shown for
> threads aren't really "process id's" in the traditional sense and
> there is no folder under /proc for them. My app has pid 12397 and one
> of the threads has pid 12404. To look up the thread pid, one needs to
> look under /proc/12397/task/12404.
>
> So, mystery (for me) solved. Thanks for all the replies!
>

Yes, you got it. When htop claims it's showing PIDs, it's actually
lying; in fact it's showing the TIDs (thread ids), and they're
different even for multiple threads within the same thread group. (For
processes with just a single thread however, TID and PID are equal)

Regards,
aranea

On Sat, Oct 13, 2012 at 4:18 PM, Canek Peláez Valdés <caneko@gmail.com> wrote:
> On Sat, Oct 13, 2012 at 2:50 PM, Michael Mol <mikemol@gmail.com> wrote:
> [snip]
>> (Well, I'm not certain that POSIX thinks of threads as parents to each other.
>
> Hence the reason I put "parent" in quotes, and I specified "actually,
> the thread that created it".
>
>> 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.
>
> Yeah, none of them "easy and quickly" to use, or at least not if you
> compare it with shared memory.

I assume you mean 'shared memory' in the 'many threads to an address
space', not the /dev/shm sense.

>
>> 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.
>
> Yup, certainly neither "easy" nor "quick".

In C (or C++, or any language capable of directly manipulating mmapped
regions), that's about as dead simple as it gets. Nothing else comes
close to that degree of efficiency for that degree of simplicity.

>
>> 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.
>
> You right, of course; it has nothing to do with the discussion at
> hand. Is just that I *really* like dbus, and I preferred it over
> almost any other IPC mechanism in Linux.

I know how much you like dbus. I just didn't care for the
implication that it was the only mechanism of note. There are other
extraordinarily important mechanisms.

>
>>> 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'
>
> OK, I will rephrase it: Google Chrome is the first *relevant* desktop
> program in Linux which uses several processes runnning under the same
> GUI.

Chrome was certainly the first *web browser* to take fault
segmentation through separate processes that far. Before Chrome,
Firefox used a separate process to thunk between the 32-bit Flash
plugin and the 64-bit Firefox process on amd64 machines.

Sticking with Desktop systems (so, not touching on SCADA), and
sticking with Linux (so, not discussing the extensive use of ActiveX
and OLE on Windows), we're left looking for some other multiprocess
desktop applications. Here's a quick list of reasonably well-known
ones:

* VLC, ffmpeg and xine, which all used the xshm extension as a shared
memory IPC mechanism to push video data rapidly to the X server (a
separate process)
* Everything in GNOME that ever used CORBA. I presume there was
something similar for performing RPC calls within the KDE setup.

--
:wq

Am 14.10.2012 01:20, schrieb Michael Mol:
> On Sat, Oct 13, 2012 at 4:18 PM, Canek Peláez Valdés <caneko@gmail.com> wrote:
>> On Sat, Oct 13, 2012 at 2:50 PM, Michael Mol <mikemol@gmail.com> wrote:
>> [snip]
>>> (Well, I'm not certain that POSIX thinks of threads as parents to each other.
>>
>> Hence the reason I put "parent" in quotes, and I specified "actually,
>> the thread that created it".
>>
>>> 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.
>>
>> Yeah, none of them "easy and quickly" to use, or at least not if you
>> compare it with shared memory.
>
> I assume you mean 'shared memory' in the 'many threads to an address
> space', not the /dev/shm sense.
>

If we really want to be nit-picking, we have to assume 'shared memory'
as in malloc'ed [1] or stack memory. Anonymous mmap'ed memory mappings
are preserved across forks and changes in them can be shared since
kernel 2.4.

[1] Yes, I know that malloc uses mmap but its mappings are MAP_PRIVATE.

Regards,
Florian Philipp