On Tue, Feb 8, 2011 at 10:55 PM, Matthew Mondor <mm_li...@pulsar-zone.net>wrote:
> - Memory custom-allocated using ecl_alloc() or ecl_alloc_align() in
> C-inline code will automatically get garbage collected if no longer
> referenced
>
True.
> - If a finalizer is wanted at GC collect/destruction time,
> si_set_finalizer() can be called with the cl_object of the foreign
> pointer and the cl_object of a custom finalizer function which will
> be called by the GC before such memory is reclaimed
>
Also true.
> - If wanted, ecl_delloc() may be used to haste destruction of an
> allocated object, and any custom registered finalizer will also
> automatically/implicitely be called
>
No. Various things.
The first one is that finalizers are not immediately called during garbage
collection. That would be insane, because arbitrary lisp code can only be
invoked when memory allocation is possible. Instead, a garbage collection
may trigger a finalization process which first revives the object, then,
possibly in the next GC cycle, finalizes it and finally, being zeroed
memory, it gets deallocated.
Second, ecl_dealloc() is just a hint to the garbage collector. Memory may or
may not be marked as unused immediately, but even then, finalization will
not be called until the GC cycle process I mentioned before happens. In
general this is true for all garbage collectors: finalization is associated
to GC not to "deallocation", an operation which is too costly if carried on
fully.
So if you want deterministic finalization, first finalize the object and
_then_ deallocate it.
Juanjo
--
Instituto de Física Fundamental, CSIC
c/ Serrano, 113b, Madrid 28006 (Spain)
http://juanjose.garciaripoll.googlepages.com
------------------------------------------------------------------------------
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb
_______________________________________________
Ecls-list mailing list
Ecls-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ecls-list
