[omniORB] deleting active servants
baileyk at schneider.com
baileyk at schneider.com
Fri Dec 19 08:57:53 GMT 2003
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
More information about the omniORB-list
mailing list