Callbacks never move, and they correctly deal with movable values referenced in the closure, so the only issue should be whether the GC reclaims a cllacbk. It can be tricky to make sure that a callback is not GCed too early, though.
As a test, you might try specifying `#:keep' as a function that put its callback argument in a new immobile cell. Assuming that you never free the cell, then the callback should never get GCed. At Mon, 12 Nov 2012 01:14:03 -0500, Jon Zeppieri wrote: > I'm running into a problem using the ffi, and I think it has to do > with passing a struct containing a number of callbacks to a foreign > function. The foreign code hangs on to this struct and may invoke the > callbacks any number of times. > > When the GC runs, things go south quickly. I'm pretty sure the reason > is that the callbacks are getting moved by the GC, and the foreign > code is left with a struct full of bad pointers. This seems to be > confirmed by the ffi docs: > > === > Structs are allocated as atomic blocks, which means that the garbage > collector ignores their content. Thus, struct fields can hold only > non-pointer values, pointers to memory outside the GC’s control, and > otherwise-reachable pointers to immobile GC-managed values (such as > those allocated with malloc and 'internal or 'internal-atomic). > === > > I found this old message from Matthew > [http://lists.racket-lang.org/users/archive/2010-July/040480.html], > but I think his suggestion to define the callbacks at the module > top-level only prevents them from being reclaimed, not from being > moved. > > It seems that I need either an immobile closure pointer or a way of > sending callbacks to the foreign code without making them invisible to > the GC. > > Any ideas? > > -Jon > > ____________________ > Racket Users list: > http://lists.racket-lang.org/users ____________________ Racket Users list: http://lists.racket-lang.org/users
