[omniORB] Bug in omniOrb thread handling?

[Luke Deller]

Hi Thomas,

On Wed, 2005-07-20 at 18:29 +0200, Thomas Richter wrote:
> sorry to bring up this issue again, but I haven't received
> a useful comment on this one here.

Did you see the email from Thomas Lockhart querying the large
maxServerThreadPoolSize setting?  Your kernel/glibc may not be
configured to allow creating so many threads, though I doubt your thread
pool is growing that large from what you say in your email.

> I've scanned thru the source, but found nowhere any "pthread_join"
> that could have been called. Thus to my analysis, the zombies remain
> around here because they are never joined back when they die away, and
> at some point the process table just overruns. At that point, the
> communication from clients to the server breaks down because no
> working thread can be allocated for a new task at hand.

OmniORB doesn't use pthread calls directly; it uses the omnithread
library which provides a cross platform C++ thread API.

In this case the omniAsyncWorker thread is started as "detached" (due to
the call to start() rather than start_undetached() in its constructor).
This results in a call to pthread_detach() when using pthreads, and so a
pthread_join is not needed (nor allowed).

Since you are finding that these threads are not being cleaned up, then
perhaps your system's pthread implementation is faulty?  Are you
interfering with signals / signal handling at all?

Regards,
Luke.