add ftype-scheme-object-pointer and related foreign-pointer extensions
#897
Conversation
|
This change helps close a gap between the Chez Scheme and Racket FFIs. It builds on the |
There was a problem hiding this comment.
This is a pretty big set of changes, and I've skimmed a bit to go through it.
Generally, I think this makes sense. From a practical perspective, it seems like this is specifically useful for referencing into bytevector and flvector, with any other type requiring some knowledge of the internal representation consistent with the object->reference-address.
An ftype pointer to a Scheme object is useful to communicate the address of a bytevector or flvector (like `object->reference-address`) in the same places that ftype pointers can be used. There's a key difference between using these new pointers and constructing a pointer with the result of `object->reference-address`: GC cooperation with a Scheme-object pointer ensures that the address does not go stale. Instead, the address is extracted just after moving into a context where a collection cannot occur (e.g., a foreign call without `__collect_safe`). With Scheme-object pointers as a way to unify GCable and foreign references through the ftype interface, some further additions give the ftype layer flexiblity similar to the lower-level `foreign-ref` API, which extracts data from a reference without a declared/checked foreign representation. The `ftype-any-ref` and `ftype-any-set!` forms cover pointer access and update, and `ftype-pointer` is allowed as a ftype-name for a generic pointer type. In addition, `ftype-scheme-object-pointer` works as an ftype-name for a pointer to a GCable object. In the case of an `(& <ftype>)` argument or result, `(& <ftype> ftype-pointer)` can be used to accept/allocate a generic pointer record instead of a <ftype>-specific pointer record, and similarly `(& <ftype> ftype-scheme-object-pointer)`. The key changes are fairly modest, but there are many additional changes just to expand plumbing. The most tedious change is that the internal `$make-record-type` function has a new argument that can turn on GC cooperation for Scheme-object ftype pointers. Most of the rest is about making foreign-call pointer arguments and results distinguish a predicate for argument checking from the rtd used to create pointer objects.
An ftype pointer to a Scheme object is useful to communicate the address of an bytevector or flvector (like
object->reference-address) in the same places that ftype pointers can be used. There's a key difference between using these new pointers and constructing a pointer with the result ofobject->reference-address: GC cooperation with a Scheme-object pointer ensures that the address does not go stale. Instead, the address is extracted just after moving into a context where a collection cannot occur (e.g., a foreign call without__collect_safe).With Scheme-object pointers as a way to unify GCable and foreign references through the ftype interface, some further additions give the ftype layer flexiblity similar to the lower-level
foreign-refAPI, which extracts data from a reference without a declared/checked foreign representation. Theftype-any-refandftype-any-set!forms cover pointer access and update, andftype-pointeris allowed as a ftype-name for a generic pointer type. In addition,type-scheme-object-pointerworks as an ftype-name for a pointer to a GCable object. In the case of an(& <ftype>)argument or result,(& <ftype> ftype-pointer)can be used to accept/allocate a generic pointer record instead of a -specific pointer record, and similarly(& <ftype> ftype-scheme-object-pointer).The key changes are fairly modest, but there are many additional changes just to expand plumbing. The most tedious change is that the internal
$make-record-typefunction has a new argument that can turn on GC cooperation for Scheme-object ftype pointers. Most of the rest is about making foreign-call pointer arguments and results distinguish a predicate for argument checking from the rtd used to create pointer objects.