[omniORB] Is resolve_initial_references() implemented right?

[Robin Princeley]

I've done something similar, one server (a Win2000 service) with plugins
(DLLs) that serve different objects. The ORB is managed by the main
service, but shared by all modules loaded by the process (all linked to
omniORB DLL).


.princeley

> -----Original Message-----
> From: owner-omniorb-list@uk.research.att.com [mailto:owner-omniorb-
> list@uk.research.att.com] On Behalf Of Maged Mokhtar
> Sent: Thursday, December 20, 2001 8:51 PM
> To: 'Jaap de Wolff'; 'Duncan Grisby'
> Cc: Omniorb-List (E-mail)
> Subject: RE: [omniORB] Is resolve_initial_references() implemented
right?
> 
> 
> > Why?  Why not make them share a single version of the omniORB
library?
> > What advantage is there in trying to give each DLL its own version
of
> > omniORB?
> 
>    [Jaap de Wolff]
> >> When I use Load Library to load a dll, this dll will first load the
> >> dll's it is depending on. It will share the code, but not the data.
> (There
> >> are ways to make it possible to let DLL's share data also, but you
have
> to
> >> do this in a ugly way).
> 
>  This does not answer the question but rather proves the point you
should
> use
>  one shared version of the omniORB library ( we want to share the data
! )
> 
>  o If you want to share data use 1 copy of the library.
>  o If, for some reason, you do not want to share data between dlls,
then
> use
> multiple
>    copies.
> 
>  As an example, the c runtime library dll ( msvcrt.dll ) , you should
> share
> 1 copy
>  to be used by all other modules in your process. If for some reason
you
> chose to use
>  multiple copies, that is fine, but if for example you allocate a
pointer
> in
> one module
>  and free it in another your process will crash.
> 
> 
> 
>