[omniORB] omnithread memory leak

Carlson, Andy andycarlson@ipo.att.com
Thu, 28 Oct 1999 01:06:46 -0700


Sai Lai,

Thanks for the response.

>> BTW, this is occurring with about 70 threads in existence, 50
>> of which are tying up Solaris LWPs. Anyone know how to ask
>> Solaris to allow more LWP's?

>On a Solaris 2.5.1 machine, I can do way beyond this limit (over a hundred
>before I stop trying). On a solaris 2.7 machine running the same binary
>(i.e. compiled for 2.5.1), I see the same behaviour as you do plus some
>error message from the thread library about resource exhaustion. I wonder
if
>this is a runtime library limitation or a bug or simply an OS/kernel
>configuration option. I don't know if there is an API to adjust this limit.

I managed later on to do a lot better than this too. It seems that the
EAGAIN
was actually referring to file handle exhaustion. I had upped the ulimit -n
but
had mixed up my shell windows when I ran this test, hence managing to
confuse myself!

Solaris does have an API thr_setconcurrency which causes it to fire up
a specified number of LWP's but I found that this made no actual difference
to the behaviour of my app because LWP creation wasnt really the primary
cause of the problem - interestingly I still got EAGAIN with about 50 LWPs
assigned to threads, even though the process had 100 LWPs at its disposal.

I'm now running with ulimit -n set to 1024 and have managed to run up to
256 concurrent threads without any thread or LWP creation problems. This 
is now reaching the limit of my current ability to generate load.

I think that an interesting lesson I have learned while doing these tests is
just how many different ways that file handle exhaustion can manifest itself
-
even during thread creation, it has at least 2 behaviours - a graceful
EAGAIN
response and a console 'libthread panic' message. It also has a myriad
detrimental effects on sockets of course. The conclusion I have come to is
that my code must protect itself from the possibility of hitting these
limits
rather than trying to deal with their effects gracefully (but I try to do
this as 
well!)

Andy
----------------------------------------------------------------------------
-----------
Andy Carlson. AT&T Labs (UK)   	Tel: +44 1527 495258
E-Mail: andycarlson@ipo.att.com	Fax: +44 1527 495229