[gentoo-user] Is my system (really) using nptl

[gentoo-user] Is my system (really) using nptl

[Timur Aydin]

Hi,

I have done many tests on my ~x86 system to confirm that it is nptl based:

- I have the nptl and nptlonly use flags in my make.conf and my system
is up to date.

- Running /lib/libc.so.6 shows:

ta@bonsai ~ $ /lib/libc.so.6
GNU C Library stable release version 2.15, by Roland McGrath et al.
Copyright (C) 2012 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
Compiled by GNU CC version 4.5.3.
Compiled on a Linux 3.5.0 system on 2012-09-10.
Available extensions:
        C stubs add-on version 2.1.2
        crypt add-on version 2.1 by Michael Glad and others
        Gentoo patchset 21
        GNU Libidn by Simon Josefsson
        Native POSIX Threads Library by Ulrich Drepper et al
        Support for some architectures added on, not maintained in glibc
core.
        BIND-8.2.3-T5B
libc ABIs: UNIQUE IFUNC
For bug reporting instructions, please see:
<http://www.gnu.org/software/libc/bugs.html>.

- getconf also indicates nptl:

ta@bonsai ~ $ getconf GNU_LIBPTHREAD_VERSION
NPTL 2.15


Yet, when I look at the process list, I am seeing all programs that use
threads having uniquey pid's for each thread. I even compiled a simple
program that just creates 5 threads, each sleeping forever. Again, each
thread had a unique pid.

I have also checked the kernel config. FUTEX support was enabled, but
the top level selector (EXPERT options) was not selected. I guess the
top level selector just exposes the FUTEX selector and doesn't really
affect whether it is enabled or not.

So, what I am wondering now, is my system configured for NPTL or not?

-- 
Timur

Re: [gentoo-user] Is my system (really) using nptl

[Canek Peláez Valdés]

On Fri, Oct 12, 2012 at 8:24 AM, Timur Aydin <ta@taydin.org> wrote:
> Hi,
>
> I have done many tests on my ~x86 system to confirm that it is nptl based:
>
> - I have the nptl and nptlonly use flags in my make.conf and my system
> is up to date.
>
> - Running /lib/libc.so.6 shows:
>
> ta@bonsai ~ $ /lib/libc.so.6
> GNU C Library stable release version 2.15, by Roland McGrath et al.
> Copyright (C) 2012 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.
> There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
> PARTICULAR PURPOSE.
> Compiled by GNU CC version 4.5.3.
> Compiled on a Linux 3.5.0 system on 2012-09-10.
> Available extensions:
>         C stubs add-on version 2.1.2
>         crypt add-on version 2.1 by Michael Glad and others
>         Gentoo patchset 21
>         GNU Libidn by Simon Josefsson
>         Native POSIX Threads Library by Ulrich Drepper et al
>         Support for some architectures added on, not maintained in glibc
> core.
>         BIND-8.2.3-T5B
> libc ABIs: UNIQUE IFUNC
> For bug reporting instructions, please see:
> <http://www.gnu.org/software/libc/bugs.html>.
>
> - getconf also indicates nptl:
>
> ta@bonsai ~ $ getconf GNU_LIBPTHREAD_VERSION
> NPTL 2.15
>
>
> Yet, when I look at the process list, I am seeing all programs that use
> threads having uniquey pid's for each thread. I even compiled a simple
> program that just creates 5 threads, each sleeping forever. Again, each
> thread had a unique pid.
>
> I have also checked the kernel config. FUTEX support was enabled, but
> the top level selector (EXPERT options) was not selected. I guess the
> top level selector just exposes the FUTEX selector and doesn't really
> affect whether it is enabled or not.
>
> So, what I am wondering now, is my system configured for NPTL or not?

You arouse my curiosity. Maybe there is a bug in glibc in ~x86; I'm
running stable (but with vanilla sources 3.6.0), and I have basically
the same setup as you: my glibc states that it has NTPL, getconf also
says it so, and I have FUTEX support enabled. I just don't set ntpl
nor ntplonly in my use flags (I was under the impression they were
enabled by default). My little program with 5 threads gets listed as a
single PID in my "ps x" output.

sys-libs/glibc-2.15-r2, no use flags set (except for multilib, which
is mandatory)
sys-kernel/vanilla-sources-3.6.1

Regards.
-- 
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

Re: [gentoo-user] Is my system (really) using nptl

[Volker Armin Hemmann]

Am Freitag, 12. Oktober 2012, 16:24:59 schrieb Timur Aydin:
> Hi,
> 
> I have done many tests on my ~x86 system to confirm that it is nptl based:
> 
> - I have the nptl and nptlonly use flags in my make.conf and my system
> is up to date.
> 
> - Running /lib/libc.so.6 shows:
> 
> ta@bonsai ~ $ /lib/libc.so.6
> GNU C Library stable release version 2.15, by Roland McGrath et al.
> Copyright (C) 2012 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.
> There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
> PARTICULAR PURPOSE.
> Compiled by GNU CC version 4.5.3.
> Compiled on a Linux 3.5.0 system on 2012-09-10.
> Available extensions:
>         C stubs add-on version 2.1.2
>         crypt add-on version 2.1 by Michael Glad and others
>         Gentoo patchset 21
>         GNU Libidn by Simon Josefsson
>         Native POSIX Threads Library by Ulrich Drepper et al
>         Support for some architectures added on, not maintained in glibc
> core.
>         BIND-8.2.3-T5B
> libc ABIs: UNIQUE IFUNC
> For bug reporting instructions, please see:
> <http://www.gnu.org/software/libc/bugs.html>.
> 
> - getconf also indicates nptl:
> 
> ta@bonsai ~ $ getconf GNU_LIBPTHREAD_VERSION
> NPTL 2.15
> 
> 
> Yet, when I look at the process list, I am seeing all programs that use
> threads having uniquey pid's for each thread. I even compiled a simple
> program that just creates 5 threads, each sleeping forever. Again, each
> thread had a unique pid.
> 

and that is how it is done, isn't it?

> I have also checked the kernel config. FUTEX support was enabled, but
> the top level selector (EXPERT options) was not selected. I guess the
> top level selector just exposes the FUTEX selector and doesn't really
> affect whether it is enabled or not.

indeed.

> 
> So, what I am wondering now, is my system configured for NPTL or not?

pretty sure: yes.

How about less YOURAPP: 
Dynamic section at offset ... contains 27 entries:
  Tag        Type                         Name/Value
 0x0000000000000001 (NEEDED)             Shared library: ....
 0x0000000000000001 (NEEDED)             Shared library: [libpthread.so.0]
?

-- 
#163933

Re: [gentoo-user] Is my system (really) using nptl

[Timur Aydin]

>> So, what I am wondering now, is my system configured for NPTL or not?
> 
> pretty sure: yes.
> 
> How about less YOURAPP: 
> Dynamic section at offset ... contains 27 entries:
>   Tag        Type                         Name/Value
>  0x0000000000000001 (NEEDED)             Shared library: ....
>  0x0000000000000001 (NEEDED)             Shared library: [libpthread.so.0]
> ?

That's what my app has.

0x00000001 (NEEDED)              Shared library: [libpthread.so.0]

So isn't the process supposed to have one pid, regardless of how many
threads it has created?

-- 
Timur

Re: [gentoo-user] Is my system (really) using nptl

[Mark Knecht]

Take look here. The answer is, I think, not necessarily.

 http://www.makelinux.net/alp/032

HTH,
Mark

Re: [gentoo-user] Is my system (really) using nptl

[Timur Aydin]

On 10/13/12 04:11, Mark Knecht wrote:
> Take look here. The answer is, I think, not necessarily.
> 
>  http://www.makelinux.net/alp/032
> 

Hello Mark,

Thank you for the link to an excellent book. However, it seems the book
is talking about linuxthreads by Xavier Leroy, not nptl. I am well aware
that linuxthreads uses LWP's to implement threads and as a result, each
thread has a separate, unique pid.

I did a few more tests using gdb and my simple app. I am seeing the
SIG32 signal and the lack of the manager threads. So everything hints
that I am indeed using nptl, but the separate process id's still doesn't
make sense...

-- 
Timur

Re: [gentoo-user] Is my system (really) using nptl

[Volker Armin Hemmann]

Am Samstag, 13. Oktober 2012, 14:15:50 schrieb Timur Aydin:
> On 10/13/12 04:11, Mark Knecht wrote:
> > Take look here. The answer is, I think, not necessarily.
> > 
> >  http://www.makelinux.net/alp/032
> 
> Hello Mark,
> 
> Thank you for the link to an excellent book. However, it seems the book
> is talking about linuxthreads by Xavier Leroy, not nptl. I am well aware
> that linuxthreads uses LWP's to implement threads and as a result, each
> thread has a separate, unique pid.
> 
> I did a few more tests using gdb and my simple app. I am seeing the
> SIG32 signal and the lack of the manager threads. So everything hints
> that I am indeed using nptl, but the separate process id's still doesn't
> make sense...

or you made a mistake somewhere in your app. 

-- 
#163933

Re: [gentoo-user] Is my system (really) using nptl

[Michael Mol]

On Sat, Oct 13, 2012 at 7:15 AM, Timur Aydin <ta@taydin.org> wrote:
> On 10/13/12 04:11, Mark Knecht wrote:
>> Take look here. The answer is, I think, not necessarily.
>>
>>  http://www.makelinux.net/alp/032
>>
>
> Hello Mark,
>
> Thank you for the link to an excellent book. However, it seems the book
> is talking about linuxthreads by Xavier Leroy, not nptl. I am well aware
> that linuxthreads uses LWP's to implement threads and as a result, each
> thread has a separate, unique pid.
>
> I did a few more tests using gdb and my simple app. I am seeing the
> SIG32 signal and the lack of the manager threads. So everything hints
> that I am indeed using nptl, but the separate process id's still doesn't
> make sense...

I'm a little late to the conversation...but is there an NPTL-directed
sample program somewhere you can use as a baseline? i.e., to be able
to say, "if this works, I know NPTL does, and I know what an NPTL
program looks like at the system level."

-- 
:wq

Re: [gentoo-user] Is my system (really) using nptl

[Canek Peláez Valdés]

On Sat, Oct 13, 2012 at 7:09 AM, Volker Armin Hemmann
<volkerarmin@googlemail.com> wrote:
> Am Samstag, 13. Oktober 2012, 14:15:50 schrieb Timur Aydin:
>> On 10/13/12 04:11, Mark Knecht wrote:
>> > Take look here. The answer is, I think, not necessarily.
>> >
>> >  http://www.makelinux.net/alp/032
>>
>> Hello Mark,
>>
>> Thank you for the link to an excellent book. However, it seems the book
>> is talking about linuxthreads by Xavier Leroy, not nptl. I am well aware
>> that linuxthreads uses LWP's to implement threads and as a result, each
>> thread has a separate, unique pid.
>>
>> I did a few more tests using gdb and my simple app. I am seeing the
>> SIG32 signal and the lack of the manager threads. So everything hints
>> that I am indeed using nptl, but the separate process id's still doesn't
>> make sense...
>
> or you made a mistake somewhere in your app.

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>

static pthread_mutex_t mutex = PTHREAD_MUTEX_INITIALIZER;
static int keep_running;

static void*
my_thread(void* data)
{
	int id = *((int*)data);
	int count = 0;

	sleep(id);
	printf("Thread %d beginning.\n", count++);

	while (keep_running) {
		printf("Thread %d: %d.\n", id, count++);
		sleep(1);
	}
	printf("Thread %d exiting.\n", count++);
}

int
main(int argc, char* argv[])
{
	keep_running = 1;
	pthread_t a, b, c, d, e;
	int* arr[] = { NULL, NULL, NULL, NULL, NULL };
	int i;
	for (i = 0; i < 5; i++) {
		arr[i] = malloc(sizeof(int));
		*arr[i] = i;
	}
	pthread_create(&a, NULL, my_thread, arr[0]);
	pthread_create(&b, NULL, my_thread, arr[1]);
	pthread_create(&c, NULL, my_thread, arr[2]);
	pthread_create(&d, NULL, my_thread, arr[3]);
	pthread_create(&e, NULL, my_thread, arr[4]);
	sleep(60);
	pthread_mutex_lock(&mutex);
	keep_running = 0;
	pthread_mutex_unlock(&mutex);
	for (i = 0; i < 5; i++)
		free(arr[i]);
}
----------------------

Regards.
-- 
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

Re: [gentoo-user] Is my system (really) using nptl

[Mark Knecht]

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.

Cheers,
Mark

Re: [gentoo-user] Is my system (really) using nptl

[Canek Peláez Valdés]

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

Re: [gentoo-user] Is my system (really) using nptl

[Mark Knecht]

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

Re: [gentoo-user] Is my system (really) using nptl

[Matthew Finkel]

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
> 

Re: [gentoo-user] Is my system (really) using nptl

[Canek Peláez Valdés]

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

Re: [gentoo-user] Is my system (really) using nptl

[Michael Mol]

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

Re: [gentoo-user] Is my system (really) using nptl

[Timur Aydin]

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

Re: [gentoo-user] Is my system (really) using nptl

[Canek Peláez Valdés]

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

Re: [gentoo-user] Is my system (really) using nptl

[lists]

[-- Attachment #1: Type: text/plain, Size: 1566 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-user] Is my system (really) using nptl

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

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

Re: [gentoo-user] Is my system (really) using nptl

[Florian Philipp]

[-- Attachment #1: Type: text/plain, Size: 1158 bytes --]

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

Re: [gentoo-user] Is my system (really) using nptl

[Michael Mol]

On Sun, Oct 14, 2012 at 5:31 AM, Florian Philipp <lists@binarywings.net> wrote:
> 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.

Absolutely.

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

For the GNU libc, yeah. I noticed that in strace, and was amused.

-- 
:wq

Re: [gentoo-user] Is my system (really) using nptl

[Florian Philipp]

[-- Attachment #1: Type: text/plain, Size: 1576 bytes --]

Am 14.10.2012 17:07, schrieb Michael Mol:
> On Sun, Oct 14, 2012 at 5:31 AM, Florian Philipp <lists@binarywings.net> wrote:
>> 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.
> 
> Absolutely.
> 
>> [1] Yes, I know that malloc uses mmap but its mappings are MAP_PRIVATE.
> 
> For the GNU libc, yeah. I noticed that in strace, and was amused.
> 

Huh? Are there other libcs that do it differently? I can't imagine any
alternative (except of the sbrk function from the bad old days).

Regards,
Florian Philipp


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

Re: [gentoo-user] Is my system (really) using nptl

[Michael Mol]

On Sun, Oct 14, 2012 at 3:19 PM, Florian Philipp <lists@binarywings.net> wrote:
> Am 14.10.2012 17:07, schrieb Michael Mol:
>> On Sun, Oct 14, 2012 at 5:31 AM, Florian Philipp <lists@binarywings.net> wrote:
>>> 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.
>>
>> Absolutely.
>>
>>> [1] Yes, I know that malloc uses mmap but its mappings are MAP_PRIVATE.
>>
>> For the GNU libc, yeah. I noticed that in strace, and was amused.
>>
>
> Huh? Are there other libcs that do it differently? I can't imagine any
> alternative (except of the sbrk function from the bad old days).

These days, and outside of Windows? I'm not familiar with any.

-- 
:wq

[gentoo-user] Re: Is my system (really) using nptl

[James]

Florian Philipp <lists <at> binarywings.net> writes:


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

Maybe you guys should agree on tools and the analysis of the results
on the same piece of code?

Maybe a tool such as valgrind/valkyrie would help?

http://valgrind.org/docs/manual/drd-manual.html

Just a thought, on this healthy discussion that is
relevant to the understanding of the many.....

hth,
James

Re: [gentoo-user] Is my system (really) using nptl

[mike]

[-- Attachment #1: Type: text/plain, Size: 769 bytes --]

On 10/14/2012 03:19 PM, Florian Philipp wrote:
> Huh? Are there other libcs that do it differently? I can't imagine any
> alternative (except of the sbrk function from the bad old days).

Newlib at least uses sbrk, presumably because only requiring that, as
opposed to requiring a fully functional memory mapping interface which
may not exist on whatever it is ported to, is far easier.  I suspect
that other smaller and/or embedded-focused libraries that don't assume a
kernel such as Linux or BSD probably also still use sbrk.

	--- MIke

-- 
A man who reasons deliberately, manages it better after studying Logic
than he could before, if he is sincere about it and has common sense.
                                   --- Carveth Read, “Logic”


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 726 bytes --]

Re: [gentoo-user] Is my system (really) using nptl

[Volker Armin Hemmann]

Am Samstag, 13. Oktober 2012, 19:20:25 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.
> 
> >> 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.

yes, dcop. Which made it possible to script every kde app. It was also used 
for all those modules to talk to each other. Why they dumbed down to dbus - I 
don't know.
-- 
#163933