Subject: [clisp-list] howto: Finalization in CLISP (using the valid bit)

From: "Hoehle, Joerg-Cyril" <[email-masked]>
Date: Fri Jul 19 07:04:10 2002

I wrote:

>User beware: fp_valid() etc. are to be called on the 
>FOREIGN-POINTER object, which is a slot within the 
>FOREIGN-ADDRESS one (pointer indirection, not substructure).

>My extensions to the CLISP FFI (not sure it even in CVS yet) 
>provide better access to the VALID bit from Lisp: 
>(FFI:MARK-INVALID-FOREIGN foreign-address) and hide the 
>FOREIGN-POINTER vs FOREIGN-ADDRESS dichotomy.

I omitted to explain that you must not call MARK-INVALID-FOREIGN on a FOREIGN-ADDRESS object returned via :return-type ffi:c-pointer of a DEF-CALL-OUT function!

Doing so would invalidate the unique foreign session pointer (O(fp_zero) in .d code) that CLISP uses for all usual FOREIGN-ADDRESS/VARIABLE/FUNCTION objects. The FFI would become mostly unusable in your current CLISP session.

You can use MARK-INVALID-FOREIGN or mark_fp_invalid() on pointers you allocated yourself in your module's constructors (via allocate_pointer()).

For example, future CLISP (I think not yet in CVS) will do that for the yet-to-be-polished m/calloc/free interface, and already do so in CVS CLISP for the WITH-FOREIGN-OBJECT WITH-C-VAR macros.

What's important to notice:

All FOREIGN-ADDRESS objects derived from the same FOREIGN-POINTER object share the VALID bit. This can be used for dependency tracking.

For example, with the FFI on AmigaOS, all FOREIGN-FUNCTION objects from a shared library become invalid and thus not callable as soon as the library is closed.

Few month ago, I had ideas about providing a Lisp-level interface to control the dependency between FOREIGN-ADDRESS and FOREIGN-POINTER objects, but I have since forgotten what I had planned ((SET-FOREIGN-BASE x :new)??).

Regards,
	Jorg Hohle.