Re: pfdInitConverter
Jim Helman (jimh++at++surreal)
Wed, 06 Dec 95 14:18:27 -0800
> On Nov 30, 7:03pm, Fernando D. Mato Mira wrote:
> > Subject: pfdInitConverter
> >
> > >>
> > pfdInitConverter dynamically links the converter corresponding to the
> > extension ext into the current executable. This routine should be called
> > before pfConfig for all extensions that an executable will use to ensure
> > that any routines and static data required at run-time are available in
> > all Performer processes.
> > >>
> >
> > What if I don't know what converters might be needed and want to
> > minimize overhead?
> >
> >-- End of excerpt from Fernando D. Mato Mira
>
> Calling this function minimizes run-time overhead if you expect to load files
> during the application. Of course, you do not have to call it. What overhead
> you are increasing is load-time. For any real-time application, the data files
> should all be loaded before starting the run anyways. You should also use
> pfdExitConverter() to unload the DSOs. If you really have no clue what kind of
> data files you might be using, then you don't know what data files you are
> loading and thus you cannot pre-load them before run-time. So, you must live
> with the rld loading of the DSOs.
It's more than rld. Some loader DSOs also provide callbacks used in
the CULL or DRAW. These DSOs must be loaded before pfConfig(), and
pfdExitConverter() should not be called on them until that portion of
the scene graph is no longer in use.
Some releases hence, after IRIS GL is deprecated, Performer will be
replacing its current fork (non-shared address space) MP model with
sproc (shared address space). At that time, many of these MP issues
will become much simpler.
For now, the only answer to Fernando's question is to either load
before pfConfig(), or to explicitly load the DSO after pfConfig() in
all processes and *hope* that there is no conflict so that the DSO
maps in at the same virtual address in all processes.
rgds,
-jim helman
jimh++at++surreal.asd.sgi.com
415/933-1151
This archive was generated by hypermail 2.0b2
on Mon Aug 10 1998 - 17:52:06 PDT