On Oct 21, 2011, at 2:30 PM, Matthew Flatt wrote: > > In case it helps, I'm thining of adding something like the following to > the docs: > > > For the following scenarios, assume > > * A `define-mylib' form of the sort that `ffi/unsafe/define' would > produce. > > * A C function f() that expects a pointer to few bytes that it will > read/write, and that will be found by `define-mylib'. > > * No calls back to Racket functions or the Racket run-time system by > f(). > > > 1. > (define-mylib f (_fun _pointer -> _void)) > (define p (malloc 'atomic 1024)) > > (f p) > > This is ok. Although the data allocated by `malloc' can move around, > `p' will always point to it, and no GC will happen between the time > that the address is extracted form `p' to pass to f() and when f() > returns.
Okay, got it. I see now that cpointers track correctly across GC. This cleans up my code substantially, because I can e.g. perform s16vector->cpointer just once, rather than just before every call. Many thanks. This passage was extremely helpful to me. Naturally, its utility depends on the programmer actually reading it in the manual.... Re the original bug: Mercifully, my working assumption turned out to be wrong, and the problem was a simple bug on my part. Whew! Many thanks for your help! John
smime.p7s
Description: S/MIME cryptographic signature
_________________________________________________ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
