This is the mail archive of the libc-alpha@sources.redhat.com mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]