Bug 62603 - pthread_create forks process instead of spawns thread?
Summary: pthread_create forks process instead of spawns thread?
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: glibc (Show other bugs)
(Show other bugs)
Version: 7.2
Hardware: i686 Linux
medium
medium
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact: Brian Brock
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2002-04-02 23:05 UTC by Rick Meyer
Modified: 2016-11-24 15:27 UTC (History)
1 user (show)

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


Attachments (Terms of Use)

Description Rick Meyer 2002-04-02 23:05:35 UTC
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 09:19:50 UTC
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.