Just Launched: You can now import projects and releases from Google Code onto SourceForge
We are excited to release new functionality to enable a 1-click import from Google Code onto the Allura platform on SourceForge. You can import tickets, wikis, source, releases, and more with a few simple steps. Read More
Sam Steingold wrote:
>no, set-foreign-pointer sets fa_base of model to fv_address of problem.
>problem can be collected without collecting its fv_address.
>I don't see how this can work.
I still think it can work. One has to think about the three objects =
that every #<FOREIGN-VARIABLE> involves (#<FOREIGN-ADDRESS> and =
#<FOREIGN-POINTER>) and decide where to put the finalizer.
Maybe you should try to put the problem finalizer on the =
foreign-pointer, not the foreign-variable? That's in line with my =
suggestion to have the models share their pointer with the problem: as =
long as a model is reachable, the problem pointer is reachable as well =
and the problem finalizer will not be called (while the problem's =
#<foreign-variable> object may be unreachable already).
If the users calls destroy-problem explicitly, the pointer gets =
invalidated and subsequent calls to destroy-model could be used to =
signal a protocol error, i.e. a fault in the program.
The explicit destroy calls could be advertised to the user as a means of =
early resource reclamation. You said these data vectors could be large. =
Or just leave it all to GC (via finalization).