[omniORB] OmniNames crashing

[Sai-Lai Lo]

>>>>> Bruce Visscher writes:

> Okay, so now we have three different platforms exhibiting this bug.
> Since it apparently started happening somewhat recently, perhaps it has
> something to do with the introduction of the omniORB_Ripper thread?

> Is there any hope that this problem will go away under omniORB 3?

> I recall uncovering a problem in this area before, but the design has
> changed somewhat since then.

This part of the ORB is essentially the same in omniORB 3 so I would like
to see the problem identified before omniORB 3 exits its current
pre-release status (which we hope is real soon now).

We know the strand assertion failure caused by thread create failure inside
the ctor of tcpSocketWorker has been fixed. (By the way, if thread create
fails, one should look into how to increase the operating system imposed
limit on the no. of threads allowed per process.) So please use the latest
2.8 source from our cvs repostory or ftp snapshots.

The design has changed a bit from 2.7. Basically the ripper thread is the
one that goes in to do a shutdown system call. The scavenger thread only
keeps all the counters running and when one goes to zero it enqueues the
strand to the ripper. This is necessary because on some platforms I'm
seeing occasionally long delays inside the shutdown system call. I don't
want the scavenger thread to be blocked in this way when it is holding a
mutex that blocks all activities associated with the same remote address
space.


Sai-Lai


-- 
Sai-Lai Lo                                   S.Lo@uk.research.att.com
AT&T Laboratories Cambridge           WWW:   http://www.uk.research.att.com 
24a Trumpington Street                Tel:   +44 1223 343000
Cambridge CB2 1QA                     Fax:   +44 1223 313542
ENGLAND