<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div>Dear Marc,<br></div><div><br></div><div>Sometimes I have a Scheme u8vector - a normal ___MOVABLE one, not ___STILL - and I have some C object such as a void* malloc()ation.<br></div><div>Right now, to move blobs between Scheme and C, I need to carry out two steps: |##still-copy| the u8vector so it becomes ___STILL, and then in a c-lambda, memcpy() the ___STILL u8vector's contents to the C void* .<br></div><div><br></div><div>Ideally this could be done in one single step, by a Gambit primitive, which both has access to the void* fixed memory address *AND* to the u8vector in accordance to its current memory location under the GC/automatic memory management.<br></div><div><br></div><div>Do you offer a procedure something like (##u8vector-copy-to-ffi-static-ptr movable-u8v ptr length) ?</div><div>And also in the opposite direction, (##copy-ffi-static-ptr-to-u8vector void* length movable-u8v offset)</div><div>This would save me of one cycle of actually-unnecessary copying.<br></div><div><br></div><div>Motivation: when I pass a u8vector as scheme-object into the FFI as ___SCMOBJ, that ___SCMOBJ can be invalidated in any moment by Gambit's GC/memory management and for this reason I can only work with ___STILL objects in C. A Gambit primitive is not subject to this limitation and therefore would help circumvent this problem.</div><div><br></div><div>Best regards,</div><div>Phil</div><div><br></div><div><br></div></div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Oct 12, 2020 at 10:30 AM Phillip Suero <<a href="mailto:philsuero@gmail.com">philsuero@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Dear Marc,<br><br>I see in <a href="https://github.com/gambit/gambit/blob/master/lib/mem.c#L1621-L1636" target="_blank">https://github.com/gambit/gambit/blob/master/lib/mem.c#L1621-L1636</a> that actually ___alloc_scmobj is a wrapper for ___alloc_scmobj_still, great that clarifies that aspect.<br><br>Just curious, when ___ps == NULL it has custom behavior (specifically it will wrap to ___alloc_scmobj_perm instead). In what situation would ___ps ever be NULL?<br><br>Thanks,<br>Phil<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Oct 12, 2020 at 10:01 AM Phillip Suero <<a href="mailto:philsuero@gmail.com" target="_blank">philsuero@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Dear Marc,<div><br>I am sending over an u8vector from the Scheme world to the C world.<br>Of course the u8vector must be still, so that its heap allocated object's memory address is not moved by Gambit's memory system.<br>To get clear on this topic, I have three quick questions for you:<br><br>(1) I see there's the function |##still-copy| in Gambit's runtime.<br>Browsing its code I don't see the keyword ___STILL mentioned anywhere in it. How does it get the ___STILL property, is that an implicit argument to ___alloc_scmobj ?<br><br>(2) Is |##still-copy| a "universal copier" of any heap allocated object, into an equivalent of itself that is ___STILL, so I can use it for, say, u32vector, floating point number, complex number, string, Scheme struct?<br><br>(3) Is there any checker in Gambit's runtime, e.g. a |##still?|, whereby I can check if a heap allocated object is ___STILL already?<br><br>Your clarification is much appreciated, thanks!<br>Phil<br></div></div>
</blockquote></div>
</blockquote></div></div></div></div>