Bug 43616 - LD_ASSUME_KERNEL changes number of pthreads available.
Summary: LD_ASSUME_KERNEL changes number of pthreads available.
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: glibc
Version: 7.1
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact: Aaron Brown
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2001-06-05 21:18 UTC by Ed McKenzie
Modified: 2016-11-24 15:05 UTC (History)
1 user (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2001-06-05 21:18:05 UTC
Embargoed:


Attachments (Terms of Use)

Description Ed McKenzie 2001-06-05 21:18:01 UTC
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 21:29:24 UTC
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.