[omniORB] ActiveX

[Helge Penne]

Hmm.  Most Singleton implementations will not delete the object until
application shutdown (after return from "main"), so if the application has
destroyed its objects, it should be safe to let the omniORB Singleton objects
deallocate.  If the application has left behind objects that are registered
with the OBB, then deallocation of the omniOBR objects themselves could
possibly present problems.  I do know know the internal workings of omniORB
well enough to tell if this is the case.  Usually, leaving an application
object "in limbo" like this would be hamless, though, since the application has
already returned from "main".

However, I guess it should be possible to implement a Singleton pattern that
would ask the object if deallocation was safe.  It should then be possible to
deallocate the internal omniORB data if and only if there are application
objects registered with the ORB.

I'm just thinking out loud here.  I've been wrong before, and I suspect I'll be
wrong again in the future.  ;-)

It really would make life easier if all libraries did a complete cleanup on
exit (either automatically or through a dedicated function).

- Helge

Sai-Lai Lo wrote:

> Helge,
>
> We do use tools like purify to ensure there is no memory leak.  In fact,
> for the past 2 years, I don't recall a single report on memory leak that
> causes the applications to grow in time.
>
> I admit there are one off allocations, singleton objects that are not
> deallocated when the program exit. However, these are one-off allocations
> that do not grow in time. Together they form the skeleton from which all
> the object implementations and object references hang off.
>
> Remember CORBA object implementations are allocated by the application and
> registered with the ORB. It is close to impossible to deallocate them
> unilaterally inside the ORB. The same applies to object references returned
> to the application.
>
> Can we deallocate everything else then? Probably yes but in doing so we
> probably have to compromise the consistency check that is in place to
> ensure that applications do not see things deleted under their feet. These
> checks are what give omniORB the robustness and for us to tell where the
> problem lies when a user reports a crash in the runtime. It is difficult
> enough to work out, just from the ORB's warning or trace message or
> assertions, if it is a real bug in the ORB or if it is just a bug in the
> application.  It will be even harder if we are not sure that the ORB is
> always internally consistent, even during shutdown.
>
> Regards,
>
> 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

--
Helge Penne (helge.penne@datarespons.no)
Senior Software Development Engineer
Data Respons AS, Postboks 489, N-1323 Høvik, Norway
Phone: +47 67112081 / 22719957 (work/home)