Marcus Barnes (marcus++at++multigen.com)
Wed, 6 May 1998 15:17:27 -0700
It is possible that a loader DSO could be unlinked (dlclose()). perfly never
does for example. Your application could, but you must realize that there are
many constraints wrt run-time un/linking. The constraints involve pfType
registration, multiprocessing address space issues and for some loaders C++
vtable access.
For example, a loader cannot be unlinked if:
- it needs to init() some pfType's then pfdInitConverter() must be called prior
to pfConfig(). This is because pfType objects include static data so the dso
must be mapped to the same address space in all processes.
- it attaches pfNodeTravFuncs() to nodes in the scene graph, then it cannot be
unlinked while those nodes exist. Similar for new derivations of pfNode,
where
C++ member functions may be called. In general, any C++ vtable must be mapped
to the same address in all processes that might invoke a member function on
an
object of that class.
- it owns a reference count on an object, via pfRef(), because the
pfdExitConverter() does not include delegation to a cleanup function (ie
pfdExitConverter_iv(), etc.) wherein such objects could be unreferenced.
So even though the pfdConverter() API implies that loaders can be unlinked. In
practice they cannot be ...
Regards.
--
+ Marcus Barnes, Technical Staff mailto:marcus++at++multigen.com +
+ Multigen Inc. http://www.multigen.com +
+ 550 S. Winchester Blvd. phoneto:1-408-556-2654 +
+ Suite 500 San Jose CA 95128 faxto:1-408-261-4103 +
=======================================================================
List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/
Submissions: info-performer++at++sgi.com
Admin. requests: info-performer-request++at++sgi.com
This archive was generated by hypermail 2.0b2 on Mon Aug 10 1998 - 17:57:22 PDT