[omniORB] nil object destruction

[Renzo Tomaselli]

Duncan,

> On Monday 3 February, "Renzo Tomaselli" wrote:
>
> > This strategy does not work when any of such nils belongs to a dynamic
> > service which has been discarded from memory because of a shutdown
procedure
> > or because it was discarded on demand during process lifecycle: then the
nil
> > points to garbage, and an access violation is granted for sure.
> > Can anyone comment on that ? Thanks,
>
> That is indeed a problem. I can't think of any easy way around it,
> other than to not call orb->destroy(). If you don't destroy the ORB,
> things like the nils are not cleaned up. It isn't possible to
> reference count the nils since the C++ mapping says you don't need
> to. I'm open to any other suggestions...

Things are a bit harder, since the crash occurs at runtime exit. That's
because _omniFinalCleanup is a singleton class (one static instance), which
destructor gets rid of all accumulated nils.
Whether the orb has been destroyed or not doesn't matter.
Not destroying the orb can be a solution if we move construction/destruction
of that class within construction/destruction of the orb. Then the
application is free to decide about not calling orb->destroy.
Btw, it's a bit unclear to me whether exiting without such a destroy raises
unexpected failures or it can be considered a normal exit. I will check it.
Regards,

Renzo Tomaselli