On Mon, Jul 12, 2010 at 1:53 PM, Edward Z. Yang <ezy...@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.le...@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. _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users