5.14 Garbage Collection Callbacks

Added in version 7.0.0.9 of package base.

A description is a vector of vectors, where each of the inner vectors describes a single call, and the calls are performed in sequence. Each call vector starts with a symbol that indicates the protocol of the foreign function to be called. The following protocols are supported: The apparently arbitrary and whimsical set of supported protocols is enough to allow DrRacket to show a garbage-collection icon.

• 'int->void corresponds to void (*)(int).

• 'ptr_ptr_ptr->void corresponds to void (*)(void*, void*, void*).

• 'ptr_ptr->save corresponds to void* (*)(void*, void*, void*), but the result is recorded as the current “save” value. The current “save” value starts as NULL.

• 'save!_ptr->void corresponds to void (*)(void*, void*), but only if the current “save” value is not a NULL pointer, and passing that pointer as the function’s first argument (so that only one additional argument is us from the description vector).

• 'ptr_ptr_ptr_int->void corresponds to void (*)(void*, void*, void*, int).

• 'ptr_ptr_float->void corresponds to void (*)(void*, void*, float).

• 'ptr_ptr_double->void corresponds to void (*)(void*, void*, double).

• 'ptr_ptr_ptr_int_int_int_int_int_int_int_int_int->void corresponds to void (*)(void*, void*, void*, int, int, int, int, int, int, int, int, int).

• 'osapi_ptr_int->void corresponds to void (*)(void*, int), but using the stdcall calling convention on Windows.

• 'osapi_ptr_ptr->void corresponds to void (*)(void*, void*), but using the stdcall calling convention on Windows.

• 'osapi_ptr_int_int_int_int_ptr_int_int_long->void corresponds to void (*)(void*, int, int, int, int, void*, int, int, long), but using the stdcall calling convention on Windows.

After the protocol symbol, the vector should contain a pointer to a foreign function and then an element for each of the function’s arguments. Pointer values are represented as for the _pointer representation defined by ffi/unsafe.

The result is a key for use with unsafe-remove-collect-callbacks. If the key becomes inaccessible, then the callback will be removed automatically (but beware that the pre-callback will have executed and the post-callback will not have executed)