[omniORB] deleting active servants

[Pánczél Levente]

Hi again

I think we're just about to get to the point:
Kendall, you said
"You cut off the quote.  I said it should not be in any shared object *which will be unloaded*."
And that's the point. I need some of my servant classes to reside in shared objects WICH CAN BE UNLOADED ON DEMAND.
I'm trying to implement a server, wich must perform the following task:
-Server starts
-Server dynamically load communication channels
-Once messages arrive, the server creates terminal handler object from the shared object.
-Server runs.
----- critical section
-User requests version upgrade (or stg. alike)
-Server stops all objects that depend on dynamically linked objects (DLO from now on.).
-DLOs (handlers than channels) are stopped. Once the last DLO of a shared object has been deleted, the shared object should be dlclosed.
-Shared objects can be replaced/deleted
----- critical section ends
-Server recreates the objects that were dropped because of the user's request.
-Server continues normal opertion with upgraded/removed subsystems

That's all I need :) This is why I use dynamic linking, and that's why I want shared objects containing servants to be closed ASAP.
Thanks for patience!
Panczel, Levente

-----Original Message-----
From:	baileyk at schneider.com [mailto:baileyk at schneider.com]
Sent:	Fri 2003-12-19 15:57
To:	Pánczél Levente
Cc:	OmniORB support
Subject:	RE: [omniORB] deleting active servants

I don't understand the difficulty in linking.  On Unix-like platforms, it
is typically allowed to have a shared object with unresolved symbols.  If
the DynamicLoadServantBase is linked into your executable, then any shared
object which needs it should load/unload just fine.  That seems to be the
way Python extensions work on Unix-alikes prior to v2.3 (when no python
shared object was created).  If DynamicLoadServantBase is in a shared
object by itself, then the executable can link to it and it will stay in
memory no matter how many other shared objects which use it get
loaded/unloaded.  Worst-case, compile it into your build of omniORB itself
as an alternative to RefCountServantBase.

All of the derived servant classes will need to include the header file and
the runtime linker will need to resolve the symbols.  On Windows or other
platforms that require symbols to be resolved at link time ( AIX I think?
), then DynamicLoadServantBase will need to be in a shared object which all
parties (executable and all servant implementation shared objects) can link
to.

You cut off the quote.  I said it should not be in any shared object *which
will be unloaded*.

Kendall



                                                                                                                                           
                      Pánczél Levente                                                                                                      
                      <Levente.Panczel at compuworx.hu        To:       <baileyk at schneider.com>, "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                                
                                                                                                                                           
                                                                                                                                           
                      12/19/2003 04:23 AM                                                                                                  
                                                                                                                                           
                                                                                                                                           




Hi Kendall!

Your idea is pretty good, and it brings me a step further, but I don't
think it will work. I really can derive a mixin from ServantBase (what you
calle DynamicLoadServantBase), and it can do the tasks described in my last
letter just fine. The only problem is, that DynamicLoadServantBase is
intended to be a base class for any of my servants (ie. TerminalObject,
compiled into TermObj.so) thus I have to link TerminalObject.o against
DynamicLoadServantBase.o to compile TermObj.so
"mixin should not be part of any shared object" --> I think this
unavoidable, since all servants (located in shared objects) would derive
from this mixin.
I really don't have any other idea now than to start diging in POA code...
:(

Cheers
Levente, Panczel