Stefan O'Rear wrote:
> On Thu, Oct 04, 2007 at 12:55:41AM +0200, Maxime Henrion wrote:
> > When writing the binding for foo_new(), I need to open a file with
> > fopen() to pass it the FILE *.  Then I get a struct foo * that I can
> > easily associate the the foo_destroy() finalizer.  However, when
> > finalizing the struct foo * object, I want to also close the FILE *
> > handle.
> > 
> > If I write a small C function for doing the finalizer myself, I still
> > wouldn't get passed the FILE * to close, only the struct foo * pointer
> > which is of no use.
> 
> Ah, yes, this does make the situation more interesting.
> 
> Looks like newForeignPtrEnv is maybe what you want?

Yeah, this is what I use now.  I wrote a player_finalizer() function in
C, that takes a FILE * and a pointer to the struct I'm handling, and
which just closes the file.  I then added these sources to the mix in my
.cabal file (with C-Sources, Extra-Includes, etc), and registered this
new finalizer using addForeignPtrFinalizerEnv.

This makes me want to ask you, what is so bad about Foreign.Concurrent
that it should be avoided at almost any cost?  It sure is likely to be
much slower than just calling a plain C finalizer, but aren't Haskell
threads super-cheap anyways?

I'm not doubting your advices at all, but want to make sure I understand
all this fully :-).

Thanks again,
Maxime


_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Reply via email to