[omniORB] ActiveX

[Steven W. Brenneis]

Sai-Lai Lo wrote:
> 
> With 2.7.1, all the internal threads should have been exited if the
> application calls BOA::destroy(). The outScavenger thread is clean up by
> the dtor of a global initialiser.
> 
> That is the theory. In practice, we found that the dtor of the global
> initialiser is not called when VB unload the DLL. Also the behaviour seems
> to differ with Windows 95/98 than Windows NT. Your notes describe the
> workaround that has to be done.
> 
> With 2.8.0 (pre2 at the moment), a new method ORB::NP_destroy() is
> added. The outScavenger is no longer clean-up by a dtor but directly as
> part of the NP_destroy(). The prefix NP_ means it is non-portable.  With
> the upcoming POA, there is a proper API to shutdown the ORB so applications
> just have to replace the call to NP_destroy() with the right one.
> To summarise, the proper way to shutdown is:
>      CORBA::BOA_ptr boa;
>      CORBA::ORB_ptr orb;
>        ...
>      boa->destroy();
>      orb->NP_destroy();
> 
> Sai-Lai
> 
> >>>>> Wittig, Juergen writes:
> 
> > this is probably due to the scanvenger thread still running in your
> > control, which will prohibit orderly control shutdown.
> 
> > Try running without the scanvenger
> 
> >> Yes, if I turn the "out scavenger" thread off by passing command line
> >> option "-ORBoutConScanPeriod 0" to ORB_init this problem doesn't
> >> occur. Thanks for this suggestion!
> 
> > Alternatively, shut the scanvenger thread down before you close the control
> 
> >> To stop the "out scavenger" thread prior to returning to VB (rather than
> > just
> >> not starting it in the first place by using "-ORBoutConScanPeriod 0"
> >> as below) call "StrandScavenger::killOutScavenger();" the include for
> >> this is <scavenger.h> which is in
> >> ".../omniORB_2.7.1/src/lib/omniORB2/orbcore" in the directory tree.
> 
> --
> 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

First, Steve painfully admits he hasn't had time to look at the 2.8.0
prerelease for NT.

With that out of the way, have you added a call to WSACleanup to the NT
implementation of the BOA::dispose member?  This call cleans up internal
WinSock memory allocation (and makes the Purify leak report easier to
read).  I have been adding this call externally to my applications which
then requires me to link with ws2_32.lib.

I have been intending to report this for quite a while but my attention
was diverted elsewhere.

Thanks for your help.
Steve Brenneis