Hi,
[Sorry for my coming out of the blue after such a long pause]
[EMAIL PROTECTED]
>The somewhat confusing manual materials are (section 8.1 of the ACL
>manual):
>Before accessing a Lisp value from C, it should be
>registered first. [...]
>A C function is provided that will return
>a pointer to the Lisp object given its index.
[...]
>If instead one were to pass the registration
>indices of these Lisp objects, one could readily find their new
>addresses using these indices following a call-back to Lisp.
I think this clearly implies that the registered object *can* move if
the C code ever uses a callback to Lisp. It's *not* pinned in memory.
Scenario
Lisp
-> C
(obtain address)
<-
Lisp...
-> C
;former address can be invalid,
;use index and provided function to obtain new address
One can derive from that that if you hold the address for a long time,
including a couple of exchanges between Lisp and C, the original address
*can* be stale.
This gives me just another reason against any sort of
"with-pointer-to-vector-data" exposed to the outside world.
Use that in tight loops inside lowest-level CFFI code (such low-level
that no application programmer ever sees it).
Don't use that in application code!
As I said long time ago, a good block API is more value to CFFI users
than dangerous pinnable vector interfaces. I haven't followed the CFFI
evolution this year and don't know if that's been done now.
Regards,
Jorg Hohle.
_______________________________________________
cffi-devel mailing list
cffi-devel@common-lisp.net
http://common-lisp.net/cgi-bin/mailman/listinfo/cffi-devel
