mallocForeignPtr vs. C

[Evan Laforge]

On Mon, Jul 12, 2010 at 1:53 PM, Edward Z. Yang <ezyang at mit.edu> wrote:
> Excerpts from Evan Laforge's message of Mon Jul 12 16:43:45 -0400 2010:
>> Yeah, that's definitely the safest and simplest.  But the copying
>> defeats the purpose of passing a pointer in the first place, which was
>> to not have to copy the giant array just to pass it.
>
> Well, if your C code wasn't squirreling away the pointer, you could have
> avoided the copy.  Memory copies in C are suprisingly cheap; I'm really
> surprised how often I see memcpy() in high performance code (though, it may be
> the case that the details of the algorithm are a much more important influence
> on performance.)

>From some quick tests, copying 32 32mb chunks takes 0.5 seconds, which
is too much lag for interactive use, but only one is only around 0.01
seconds, which is not a problem.  At the moment, I expect 32mb will be
an upper bound, so I think I can get away with copying for now.

However, I'm still curious about the funptr approach.  Does a
"wrapper" funptr callback act as a GC root?

On Mon, Jul 12, 2010 at 4:26 PM, Felipe Lessa <felipe.lessa at gmail.com> wrote:
> ... I would try to avoid having the MVar/IOVar as a CAF because of its
> unpredictability.  You can always encapsulate it as somewhere else
> (e.g. Reader monad).

Yes, I would prefer a non-horrible hack too, but it's tricky and
invasive to try to get a callback from C to haskell into the main
haskell state monad.  I would have to send a "delete this key" msg
which the main loop will later pick up, which is certainly doable,
but... invasive.