[omniORB] deleting active servants

[baileyk at schneider.com]

What you describe is one possibility.  As I said, on Unix like platforms
all of that should work just as you describe.  There may be specific linker
options needed to produce a shared object with unresolved symbols (on AIX
probably).

The other option is to treat your OwnRefCountServantBase similarly to
omniORB's RefCountServantBase.  You can put it in a shared object by
itself, link your other shared objects to it, *and* link your executable to
it just as you link both your shared objects and executable to omniORB
libs.  That way the OwnRefCountServantBase shared object gets loaded with
the executable and stays resident.  This approach should work for Windows.

I run Python 2.2 on Solaris.  There is no libpython.so created, but rather
just an executable and an archive lib (libpython.a for embedding).  The
_omniidl.so shared object which implements the IDL compiler has many Python
related undefined symbols which the dynamic linker resolves at runtime by
finding them in the executable when I do a "import _omniidl" at a Python
prompt.  Yes, dynamic linking cat work "both ways".  The shared object
being loaded may have symbols resolved by the executable.  In fact, dlopen
() does not cause the dynamic linker to resolve missing symbols in the
executable.  Those must be resolved at load time (possibly in a lazy
fashion).  The fact that your shared objects implement servant classes is
transparent to the dynamic linker.  It has no way to verify the virtual
function tables of your dynamically loaded classes match those of the base
classes being exteded (like ServantBase or your skeleton base classes).
It's up to the C++ compiler to guarantee that, which works so long as
header files haven't changed between compiling the executable and compiling
the dynamically loaded objects.  If header files have changed, the dynamic
linker won't complain but you'll get undefined behavior because the "one
definition rule" has been broken.

Kendall



                                                                                                                                    
                      Pánczél Levente                                                                                               
                      <Levente.Panczel at compuworx.hu        To:       <baileyk at schneider.com>, "support OmniORB (OmniORB support)"   
                      >                                     <omniorb-list at omniorb-support.com>                                      
                      Sent by:                             cc:                                                                      
                      omniorb-list-bounces at omniorb-        Fax to:                                                                  
                      support.com                          Subject:  RE: [omniORB] deleting active servants                         
                                                                                                                                    
                                                                                                                                    
                      01/05/2004 09:17 AM                                                                                           
                                                                                                                                    
                                                                                                                                    




Hi

I think I get it.
So you suggest me to make a class OwnRefCountServantBase, wich then cares
for dlclose() in _remove_ref().
Let's say I define this class in orcsb.h and implement _add_ref() and
_remove_ref() in orcsb.cpp
I compile these two sources to orcsb.o
I link the server application (wich dynamically loads shared objects, and
commands them to create TTerminalObject servant instances) with orcsb.o
In TermObj.h I #include orcsb.h and may inherit TTerminalObject from
OwnRefCountServantBase like:
             Class TTerminalObject: public OwnRefCountServantBase, ...
And than I can link build the shared object without to have it linked with
orcsb.o and without having it containing orcsb.cpp? And so when the
TTeminalObect implementation references ie. OwnRefCountBase::DoAnything()
then DoAnything is looked up in the server application by the dynamic link
established through dlopen. (So this means, that dlopening a file is not a
one-way link, but it also imports the clients symbols to be available by
the shared object's code?) That would really be a difference compared to
windows...
Meanwhile, I will do a test to see if this really works.
Thanks for the advice! I'll let you know what I get.
Cheers,
Panczel, Levente