Dear Marc,
I know if I have a ___STILL u8vector, if I have a blob in the C world, I can just implement a c-lambda that will memcpy() that blob into the u8vector's memory addresses.
If the u8vector is not ___STILL however, I cannot do that as the u8vector's memory address range could change during the memcpy(), is not that so.
Is there any function in Gambit to copy a byte range from a fixed memory address into a non-___STILL u8vector? E.g. (u8vector-raw-copy! (foreign-address my-c-object) u8vector 0 length)?
Or instead, is the recommendable way to do this, that I make a ___STILL u8vector, do memcpy() to it in a c-lambda, and then at return i |u8vector-copy| this u8vector, this way the resultant u8vector is non-___STILL which is best from the point of view of memory fragmentation?
Your clarification will be much appreciated!
Thanks, Phil
Afficher les réponses par date
Ah right - allocating an u8vector in the Scheme world is always preferable over allocating while in the C world (via ___alloc_scmobj() right), isn't it so?
And this is because allocating an object may involve a heap overflow exception, a resumed allocate attempt, a garbage collection, all these complexities are only offered by |##make-u8vector| defined in lib/_kernel.scm, which is very much preferable to invoke in a pure Scheme setting, is it not so
Thanks, Phil
On Fri, Nov 13, 2020 at 11:46 AM Phillip Suero philsuero@gmail.com wrote:
Dear Marc,
I know if I have a ___STILL u8vector, if I have a blob in the C world, I can just implement a c-lambda that will memcpy() that blob into the u8vector's memory addresses.
If the u8vector is not ___STILL however, I cannot do that as the u8vector's memory address range could change during the memcpy(), is not that so.
Is there any function in Gambit to copy a byte range from a fixed memory address into a non-___STILL u8vector? E.g. (u8vector-raw-copy! (foreign-address my-c-object) u8vector 0 length)?
Or instead, is the recommendable way to do this, that I make a ___STILL u8vector, do memcpy() to it in a c-lambda, and then at return i |u8vector-copy| this u8vector, this way the resultant u8vector is non-___STILL which is best from the point of view of memory fragmentation?
Your clarification will be much appreciated!
Thanks, Phil
Hi Marc,
What the OP mentions would ideally be offered through a form something like |ffi-copy-to-u8vector|, is it not? Wrote this up as a feature request here now https://github.com/gambit/gambit/issues/645 .
Best regards, Adam
On Fri, 13 Nov 2020 at 15:54, Phillip Suero philsuero@gmail.com wrote:
Ah right - allocating an u8vector in the Scheme world is always preferable over allocating while in the C world (via ___alloc_scmobj() right), isn't it so?
And this is because allocating an object may involve a heap overflow exception, a resumed allocate attempt, a garbage collection, all these complexities are only offered by |##make-u8vector| defined in lib/_kernel.scm, which is very much preferable to invoke in a pure Scheme setting, is it not so
Thanks, Phil
On Fri, Nov 13, 2020 at 11:46 AM Phillip Suero philsuero@gmail.com wrote:
Dear Marc,
I know if I have a ___STILL u8vector, if I have a blob in the C world, I can just implement a c-lambda that will memcpy() that blob into the u8vector's memory addresses.
If the u8vector is not ___STILL however, I cannot do that as the u8vector's memory address range could change during the memcpy(), is not that so.
Is there any function in Gambit to copy a byte range from a fixed memory address into a non-___STILL u8vector? E.g. (u8vector-raw-copy! (foreign-address my-c-object) u8vector 0 length)?
Or instead, is the recommendable way to do this, that I make a ___STILL u8vector, do memcpy() to it in a c-lambda, and then at return i |u8vector-copy| this u8vector, this way the resultant u8vector is non-___STILL which is best from the point of view of memory fragmentation?
Your clarification will be much appreciated!
Thanks, Phil
Gambit-list mailing list Gambit-list@iro.umontreal.ca https://mailman.iro.umontreal.ca/cgi-bin/mailman/listinfo/gambit-list
-
Adam -
Phillip Suero