Once I have a pointer to a memory block from the ffi (allocated in a shared memory space), is there a way to turn it into a standard racket flvector? I see there's a flvector->cpointer, but not the converse.
Probably not, for the reasons discussed here:
opened 06:11PM - 05 Jan 20 UTC
Is there a way to mmap some memory (a file for example, I can do this simply via… the ffi) and use that memory without copying in a bytevector? Some sort of function that sets a bytevectors storage, and locks it, so the gc doesn't touch it?
opened 06:16PM - 04 Feb 21 UTC
question
Let say I have some block of memory suitably aligned (8 bytes on my x86_64 machi… ne), of say 16 bytes, with the first 8 bytes being `(8 << 3) | 1` (in a `uint64_t` in native endianness), then create a properly tagged pointer to it with `($address->object (- ptr 1) 0)`, `ptr` being the pointer to said block of memory, then I just have successfully created a bytevector of size 8; all bytevector procedures work on this Scheme object that was _materialized_ outside the Scheme heap.
My question is, (let's suppose the block of memory is _never_ freed and reused for the sake of simplicity), is this bytevector can confuse and/or harm the garbage collector? If not, is materializing string objects in a similar fashion the same result? And what about other non-immediate values (pairs, vectors, records etc.)?
Ouch, that's not very promising indeed
You might be able to use _f64vectorffi/vector, though!
True, but that won't help me much.
The idea was to re-use all my functions defined for flvectors without having to change all the flvector-ref, etc.
Also, _f64vector uses _double*, which is slower than _double AFAIR.
(what's happening with Discourse's markdown?)
Thanks!