Bug 62603 - pthread_create forks process instead of spawns thread?
pthread_create forks process instead of spawns thread?
Status: CLOSED NOTABUG
Product: Red Hat Linux
Classification: Retired
Component: glibc (Show other bugs)
7.2
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Jakub Jelinek
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2002-04-02 18:05 EST by Rick Meyer
Modified: 2016-11-24 10:27 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2002-04-02 18:05:39 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Rick Meyer 2002-04-02 18:05:35 EST
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 4.0)

Description of problem:
I'm writing a C++ program using the pthread library and I noticed when I 
run 'ps -f' while the program is running that I see a separate process running 
for each thread. Is this a function of the ps command, since it can't display 
thread counts? Or is something wrong here?

eg : (the -c option indicates the # of threads to spawn)

[root@localhost scripts]# /home/tbench/tb -f tracks.cfg -c 10 -t 300 -s &
[1] 20414
[root@localhost scripts]# ps -f    
UID        PID  PPID  C STIME TTY          TIME CMD
root     20332 20331  0 13:57 pts/0    00:00:00 -bash
root     20414 20332  2 13:59 pts/0    00:00:00 /home/tbench/tb -f tracks.cfg -
c 10 -t 300 -s
root     20415 20414  1 13:59 pts/0    00:00:00 /home/tbench/tb -f tracks.cfg -
c 10 -t 300 -s
root     20416 20415  1 13:59 pts/0    00:00:00 /home/tbench/tb -f tracks.cfg -
c 10 -t 300 -s
root     20417 20415  0 13:59 pts/0    00:00:00 /home/tbench/tb -f tracks.cfg -
c 10 -t 300 -s
root     20418 20415  1 13:59 pts/0    00:00:00 /home/tbench/tb -f tracks.cfg -
c 10 -t 300 -s
root     20419 20415  1 13:59 pts/0    00:00:00 /home/tbench/tb -f tracks.cfg -
c 10 -t 300 -s
root     20420 20415  1 13:59 pts/0    00:00:00 /home/tbench/tb -f tracks.cfg -
c 10 -t 300 -s
root     20421 20415  1 13:59 pts/0    00:00:00 /home/tbench/tb -f tracks.cfg -
c 10 -t 300 -s
root     20422 20415  0 13:59 pts/0    00:00:00 /home/tbench/tb -f tracks.cfg -
c 10 -t 300 -s
root     20423 20415  2 13:59 pts/0    00:00:00 /home/tbench/tb -f tracks.cfg -
c 10 -t 300 -s
root     20424 20415  0 13:59 pts/0    00:00:00 /home/tbench/tb -f tracks.cfg -
c 10 -t 300 -s
root     20425 20415  1 13:59 pts/0    00:00:00 /home/tbench/tb -f tracks.cfg -
c 10 -t 300 -s


Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1. Unfortunately I can't give you the source code to this.
2. I can guarantee you that their are no fork() calls in the code though.

	

Additional info:

I have also tried this on RedHat 6.2 with the same results.
Comment 1 Jakub Jelinek 2002-04-03 04:19:50 EST
Those are threads, not separate processes. They just don't share the same pid
(and libpthread deals with this in getpid() etc.).
Up until very recently Linux kernel did not support CLONE_PID for user tasks,
so pids could not be shared at all. ATM kernel allows the sharing, but as that
means lot of changes in libpthread it was decided to deal with this only
during full libpthread rewrite.

Note You need to log in before you can comment on or make changes to this bug.