Re: [ft] Memory management and stream I/O question (Freetype v1 --> v2)

[Alex Taylor]

On Thu, 21 Mar 2013 07:29:10 +0100 (CET) Werner LEMBERG wrote:

> > Second: It's vitally important to flush (i.e. close) the Face stream
> > every time I pass control back to the application, while otherwise
> > keeping the Face object itself.  The existing (v1) code uses
> > TT_Flush_Face (which in turn calls TT_Flush_Stream).  I cannot
> > figure out what the equivalent procedure in Freetype v2.x is,
> > however.  Can anyone help with this?
> 
> There is no such functionality anymore, and noone has ever requested
> it.  May I suggest the following approach: Simply assume that FreeType
> does the right thing.  In case it doesn't, please open a bug report,
> ideally providing a patch.  It should be straightforward to add a new
> function to the API, but I would prefer if you could provide an OS/2
> specific version of `ftsystem.c' (and probably `ftdebug.c' also).

When you say "does the right thing", does then FreeType actually close the 
streams after returning the requested data?

This environment is rather unusual.  The notes provided by the original 
author (Michal Necasek) are a bit terse, but this is what he says:

   Note #2: On exit of each function reading from font file the API       
   TT_Flush_Stream() must be called. This is because file handles opened
   by this DLL actually belong to the calling process. As a consequence 
    a) it's easy to run out of file handles, which results in really    
       very nasty behavior and/or crashes. This could be solved by      
       increased file handles limit, but cannot because                 
    b) it is impossible to close files open by another process and      
       therefore the fonts cannot be properly uninstalled (you can't    
       delete them while the're open by other process)                  
   The only solution I found is very simple - just close the file before
   exiting a DLL function. This ensures files are not left open across  
   processes and other problems.                                        

The problem is that this is a shared system module which is loaded by the 
desktop shell on system boot, and not unloaded until shutdown.  If I 
understand correctly, file handles opened in response to calls to this DLL 
(especially by the desktop itself, which makes extensive use of fonts) may  
not get closed.

We maintain a cache of the last X opened faces (in an internal linked list) 
so the FT_Face objects themselves (and the data in them) are saved between 
calls; however, their associated streams must be closed at the end of every 
call to avoid the problems noted above.

Now, I imagine I could grab the face->stream handle and close it myself.  
In FT1, the library automatically re-opened the stream if necessary.  
However, I'm not sure (looking through the FT2 code) that this is still the 
case.  I suppose I could add my own wrapper functions to do this, but I 
wanted to know if there was a better way.


Incidentally, I have written a custom ftsystem implementation (and 
associated make target) with the memory-management and I/O routines 
necessary for this environment.  These are not what normal OS/2 
applications would use; the standard C library functions are sufficient for 
those.  This particular project, however, requires the use of special 
memory functions that are reserved for the desktop shell and its driver 
modules (of which this is one).  I can of course provide the custom files 
(how?); I'm just noting that they are highly specialized.


Thanks...
-- 
Alex Taylor <address@hidden>
http://www.altsan.org