This is the mail archive of the
libc-alpha@sources.redhat.com
mailing list for the glibc project.
Re: [libc-alpha] pthread_create is failing with a return value EAGAIN
- From: Kaz Kylheku <kaz at ashi dot footprints dot net>
- To: Prasad A Tunga <pratunga at in dot ibm dot com>
- Cc: drepper at redhat dot com, <libc-alpha at sources dot redhat dot com>
- Date: Fri, 15 Mar 2002 08:34:59 -0800 (PST)
- Subject: Re: [libc-alpha] pthread_create is failing with a return value EAGAIN
On Fri, 15 Mar 2002, Prasad A Tunga wrote:
> Date: Fri, 15 Mar 2002 17:38:53 +0530
> From: Prasad A Tunga <pratunga@in.ibm.com>
> To: drepper@redhat.com
> Cc: libc-alpha@sources.redhat.com
> Subject: [libc-alpha] pthread_create is failing with a return value EAGAIN
>
> Hi,
>
> My application fails because pthread_create is failing with a return value
> 11 (EAGAIN)
> after creating many threads.
Yes, it will do that. Your computer does not have unlimited resources.
EAGAIN is the UNIX-standard way of indicating that a thread cannot
be created due to resource limitations.
This is basically a CORBA application.
> I'm running this on a Linux IA64 RedHat 7.2 m/c with 2.4.9 kernel and a
> glibc version
> of 2.2.4-19.3 The problem occurs after creating around 700 threads.
The problem occurs in the software design which calls for the creation
of 700 threads. Making 700 threads won't make your application 700
times faster; threads are not hardware. This is simply not a reasonable
number of threads to create.
> Also iam sure that we are not hitting PTHREAD_THREADS_MAX limit which is
> 1024.
That is just an artificial limit.
You also have to consider how much RAM you have. Each thread has a stack
which is a two megabyte memory mapping. So 1024 threads requires 2 *
1024 megabytes of virtual address space. On an 32 bit processor, that's
half your address space. If you want lots of threads, it will behoove
you to manage your own stacks.
Lastly, your kernel will limit how many tasks you can create. Each
thread is a kernel task.
> To make sure, i even compiled glibc with higher PTHREAD_THREADS_MAX.But
> still
> the problem persists.
> So we must definitely be hitting someother kernel limits.
``Other''? PTHREAD_THREADS_MAX is not a kernel limit.
> Can you please let me know how to overcome this problem..?
Simple: count the number of peripherals that your program needs to
independently wait on on, count your number of processors, add them
together, then add some small fudge term and you probably have a good
starting value for your number of threads.
--
Meta-CVS: version control with directory structure versioning over top of CVS.
http://users.footprints.net/~kaz/mcvs.html