[omniORB] proxyObjectFactory for shared components

Renzo Tomaselli renzo.tomaselli@tecnotp.it
Tue, 27 Nov 2001 10:24:48 +0100


Duncan,
    this issue looks pretty hard to solve. While it's easy to record all
factories being loaded and to unload the right one by "this" comparison, =
the
method "lookup" offers no discriminator capabilities to select a specific
factory to use in case of multiple instances. And modifying this behavior
looks almost impossible in any reasonable way given the way lookup is use=
d.
So I'm afraid I must ensure that either a single copy of any stub is link=
ed
in a process or multiple copies remain resident once loaded.
There is a further issue here: actual constructor code in proxyFactory.cc
replaces any already loaded factory by the new one with the same repoID, =
so
that the actually used one is the very last found.
However if an application takes care of component mutual dependencies it
will load components mostly used first, so that their factories should be
preferred.
I would kindly suggest to modify proxyObjectFactory::proxyObjectFactory()=
 so
that existing factory is used whenever found during its binary search (ju=
st
drop lines #101-103).
Thanks,
                                Renzo Tomaselli
-------------------------------------------------------------------------=
--
TecnoTP s.n.c. Special Information System Design
Maso Pelauchi I38050 Ronchi Valsugana,  Trento TN  ITALY
Tel. +39 0461 773164      Fax. +39 0461 771514
e-mail: renzo.tomaselli@tecnotp.it
-------------------------------------------------------------------------=
--

-----Original Message-----
From: Duncan Grisby <dgrisby@uk.research.att.com>
To: Renzo Tomaselli <renzo.tomaselli@tecnotp.it>
Cc: Omniorb list <omniorb-list@uk.research.att.com>
Date: luned=EC 26 novembre 2001 12:34
Subject: Re: [omniORB] proxyObjectFactory for shared components


>On Tuesday 20 November, "Renzo Tomaselli" wrote:
>
>> then if any such component is unloaded at runtime then the application
>> crashes as soon as any involved interface is instantiated. This occurs
since
>> the related proxyObjectFactory is unloaded from memory thus leaving a
>> dangling pointer around (in orbcore/proxyObjectFactory.cc).
>> While all of this is true for 3.04, I would like to know about 4.0: an=
y
plan
>> to fix this behavior or is there anything I might do for that ? (the
basic
>> point is to keep track of factory indentities, so that their destructo=
rs
>> should remove the right one from the orb list).
>
>The proxyObjectFactory code hasn't changed in omniORB 4, so at the
>moment it's the same as omniORB 3. If you can come up with a patch
>that does what you want in a thread-safe and clean manner, I'll think
>about incorporating it.
>
>Cheers,
>
>Duncan.