Here is a more concrete example of what I had in mind:
The idea is to provide a link to Olabl from STk, to get a dynamically
typed front end language for interacting with and controlling
computations done in Olabl (
http://wwwfun.kurims.kyoto-u.ac.jp/soft/olabl/ )
Example:
Given the following Olabl functions,
let get_array n =
Array.create len: n fill: 0.0
let calculate_entries :array =
let n = Array.length array in
for i=0 to n-1 do
array.(i) <- sin (3.1415 *. (float i)/.(float (n-1))) ;
done
a simple C wrapper can be written for external access.
A call to get_array (from STk, through C) would return a pointer. Since
Olabl has no
more pointers to the array, any invocation of the Olabl garbage
collector may free the array -- even though STk still uses it.
On the Olabl side, this is easily fixed by registering the pointer.
After registering, the array must be explicitly unregistered before
the garbage collector will remove it or its contents.
Thus, STk now has this pointer, perhaps bound in a let:
(let ((a (get_array 10)))
;; Do something...
(calculate_entries a)
;; Do some more...
)
After this, the next STk garbage collection should free a.
Doing this properly requires a call to a custom finalization function
from the STk garbage collector; a simple call to free() will not do.
The STk manual states (p. 57) that
"Pointers defined with :dynamic-ptr are always deallocated with free()..."
-- so the get_array() wrapper should not use :dynamic-ptr --
and further
"... areas allocated with another allocator ... must be declared as
:static-ptr and freed by hand." -- which is most undesirable.
Adding a third return type, say :dynamic-finalized-ptr, would be useful.
For this type, a user-provided finalization function needs to be
provided also. This function can be called by the STk garbage collector
to deallocate the memory instead of free().
There are a few questions:
Is this a reasonable approach, or are there some subtleties that
would cause the link to fail?
Can the STk extension be readily implemented?
Any ideas/opinions/suggestions are welcome.
Thanks,
Michael
Received on Sat Mar 27 1999 - 19:34:33 CET