Re: The infamous dbase paging memory leak

New Message Reply Date view Thread view Subject view Author view

Mason D. Menninger (mason++at++praxis.jsc.nasa.gov)
Tue, 20 Apr 1999 13:54:40 -0500 (CDT)

Okay, I think we are getting somewhere now. The man page
for "fltSharedPalette" states:

          Since the loader owns the shared palette resources, via
          pfRef, these resources will persist even after the
          associated database has been deleted. Therefore the loader
          provides a function to disown and/or deallocate the shared
          palette, when using the loader as part of a database paging
          facility.

So here's the question: Even if I am clever enough to get
a pointer to a fltSharedObj that was created with the
OpenFlight loader, how do I use fltFreeSharedObj() within
the dbase process without the same catastrophic results
as using pfDelete() in the dbase process? Is there a
"fltAsyncFreeSharedObj"?

The final note of the man page says:

          fltSharedPalette will be more fully documented in a future
          release.

Any ambitious writers from MultiGen want to take a crack at it?

                        -Mason
                        mason++at++praxis.jsc.nasa.gov

> I think the flight loader performs a pfRef() call to every texture and
> Geostate that it creates. This makes it impossible for pfXXDelete() to
> remove them from memory.
> See man page for 'fltSharedPalette'. One of the Multigen Flight Loader
> pages.
>
> Mario

New Message Reply Date view Thread view Subject view Author view

This archive was generated by hypermail 2.0b2 on Tue Apr 20 1999 - 11:55:07 PDT

This message has been cleansed for anti-spam protection. Replace '++at++' in any mail addresses with the '@' symbol.