Re: [Devel] Close on exec for font files

[Scott Long]

This time you made your point much more strongly :) I hadn't realized that 
FreeType was involved at such a lower level; I had assumed that you were 
using FreeType yourself.

Then I think your fcntl() approach is the best, and you can apply it in 
ftsystem.c in the function Ft_New_Stream().

After the call to fopen() just say:

long close_flag = FD_CLOEXEC;
fcntl(fileno(file), F_SETFD, &close_flag);

I've always thought it would be nice to be able to register functions to get 
called after fork(). FreeType could register its own function to close all 
its resources. You can do this with pthreads if you have it, with 
pthread_atfork().

Scott

On Wednesday 26 December 2001 11:11 am, you wrote:
> Around 10 o'clock on Dec 26, Scott Long wrote:
> > it is better to just use that API rather than introducing UNIX-specific
> > code into a cross-platform library. If similar issues arise in Windows (I
> > have no idea, don't program Windows) then this solves the problem on both
> > platforms instead of just one.
>
> If a similar issue arrises on another platform (it doesn't on Windows),
> then the library could solve it there as well.  Here's a diagram of the
> API heirarchy I'm dealing with:
>
>       Application
>           v
>          KDE
>           v
>          Qt
>           v
>          Xft
>           v
>       FreeType
>
> The application has no idea it's using FreeType, neither does KDE, nor Qt.
> At the application level, it doesn't even know what fonts are in use; the
> toolkit selects them based on the current UI theme in use.  So, I'd have
> to add a blanket "clean up all open fonts" call at the KDE level and the Qt
> level, and then special calls at the Xft level to pass through the
> FT_Done_FreeType call.
>
> As Qt is also cross-platform, this call will not be needed *except* on
> Unix systems, where failing to call it may well cause problems.  Instead
> of forcing applications to make a call which is not always needed, it
> makes a lot more sense to have the library which knows that it is needed
> handle it transparently.
>
> The only relevant question that I can see is whether there is a case where
> this call would be incorrect, and as the internal library state gets
> destroyed across the 'exec', I find it hard to believe such a case exists.
>
> Keith Packard        XFree86 Core Team        Compaq Cambridge Research Lab
>
>
>
> _______________________________________________
> Devel mailing list
> address@hidden
> http://www.freetype.org/mailman/listinfo/devel