Bug 43616 - LD_ASSUME_KERNEL changes number of pthreads available.
LD_ASSUME_KERNEL changes number of pthreads available.
Status: CLOSED NOTABUG
Product: Red Hat Linux
Classification: Retired
Component: glibc (Show other bugs)
7.1
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Jakub Jelinek
Aaron Brown
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2001-06-05 17:18 EDT by Ed McKenzie
Modified: 2016-11-24 10:05 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2001-06-05 17:18:05 EDT
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 Ed McKenzie 2001-06-05 17:18:01 EDT
Description of Problem:
Without LD_ASSUME_KERNEL=2.2.5, the number of pthreads is limited to ~256,
while with that symbol exported the available pthreads rises to ~1024,
which is more consistent with other distributions/platforms.

How Reproducible:
100%

Steps to Reproduce:
1. Write a test program in {python|C|C++} that creates an infinite number
of threads. It should print the number of threads after the first thread
creation fails.
2. Run it without LD_ASSUME_KERNEL=2.2.5.
3. Run it again with that symbol defined.

Actual Results:
Out of the box, RHL 7.1 only supports ~256 threads on i686.

Expected Results:
Other platforms support many more threads. 

Additional Information:
none
Comment 1 Jakub Jelinek 2001-06-05 17:29:24 EDT
But, unlike when running with LD_ASSUME_KERNEL=2.2.5 (= non-LDT
based threads, no floating thread stacks), this is no hard constant.
It is as easy as
ulimit -s 2048
to get the same thread limit as without LDT based threads, but one
can even
ulimit -s 256
and get loads of threads with smaller stacks.
Of course, threads apps may call setrlimit before doing first
pthread_create instead of relying on ulimit to be called in parent
shell first.

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