[omniORB] Is resolve_initial_references() implemented right?

[Robin Princeley]

Using LoadLibrary does share the DLL across the whole process; this is a
feature I make use of.

Instances of C++ classes (or memory allocations) created in one DLL can
not be deleted in another DLL unless they same the same runtime library
(same context).


.princeley

> -----Original Message-----
> From: Jaap de Wolff [mailto:wolff@NewBridges.nl]
> Sent: Friday, December 21, 2001 12:45 PM
> To: 'Robin Princeley'; Jaap de Wolff
> Cc: 'Omniorb-List (E-mail)'
> Subject: RE: [omniORB] Is resolve_initial_references() implemented
right?
> 
> As far as I know, (and I am programming for NT for over 5 years now),
> there
> is no way of forcing that different DLL's are sharing one copy of a
file.
> By my best knowledge, when you are not loading the library explicit at
> runtime by LoadLibrary(), they will share one copy of the file, but
when
> you
> explicit load them (by using LoadLibrary) they will not share one copy
of
> the file.
> Most of the times there will be no problem, also not in OmniORB.
> Until now, the resolve_initial_references() function is the only
function
> which can not be called from the "plugin", and as long as you don't
use
> this, everything seems to work fine.
> And Robin, are you sure your plugins are using a shared version of the
ORB
> dlls?
> Are you using resolve_initial_references() in any of them? If so I'm
> interested in how you did it.
> 
> > -----Original Message-----
> > From: Robin Princeley [mailto:robin@princeley.com]
> > Sent: Thursday, December 20, 2001 09:55 middag
> > To: 'Jaap de Wolff'
> > Cc: 'Omniorb-List (E-mail)'
> > Subject: RE: [omniORB] Is resolve_initial_references() implemented
> > right?
> >
> >
> > 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.
> > >
> > >
> > >
> > >
> >
> >