guile-user
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

PATCH: docs GC protection functions


From: Aaron VanDevender
Subject: PATCH: docs GC protection functions
Date: Thu, 4 Sep 2003 20:48:58 -0400
User-agent: Mutt/1.2.5.1i

I wrote some documentation for the
scm_gc_protect/unprotect_object and scm_permanent_object.

Would anyone care to commit it (or comment on it)? I submitted
something earlier as a patch to scheme-memory.texi, but I think
it fits better in data-rep.texi.

cya
.sig


--- data-rep.texi       29 Aug 2003 23:32:21 -0000      1.14
+++ data-rep.texi       5 Sep 2003 00:17:51 -0000
@@ -1397,6 +1397,7 @@
 * Creating Instances::          
 * Type checking::                
 * Garbage Collecting Smobs::    
+* Protecting Smobs from Garbage Collection::    
 * A Common Mistake In Allocating Smobs::  
 * Garbage Collecting Simple Smobs::  
 * Remembering During Operations::  
@@ -1793,8 +1794,44 @@
 very simple.  Since collections occur at unpredictable times, it is easy
 for any unusual activity to interfere with normal code.
 
address@hidden Protecting Smobs from Garbage Collection
address@hidden Protecting Smobs from Garbage Collection
 
address@hidden A Common Mistake In Allocating Smobs, Garbage Collecting Simple 
Smobs, Garbage Collecting Smobs, Defining New Types (Smobs)
+Since the garbage collector traverses the stack looking for scheme
+objects to mark, if you have create a scheme object from C code, and
+there are no references to it on the stack (because they are all on
+the heap), then the garbage collector might free that object even
+though it is still in use. These functions let you tell the garbage
+collector that they should not be freed, even though they are not on
+the stack.
+
address@hidden {C Function} SCM scm_gc_protect_object (SCM @var{obj})
+Protects @var{obj} from being freed by the garbage collector, when it
+otherwise might be.  @code{scm_gc_protect_object}
+causes the collector to mark the object whenever it runs. When you are
+done with the object, call @code{scm_gc_unprotect_object} on the
+object. Calls to scm_gc_protect/unprotect_object can be nested, and
+the object remains protected until it has been unprotected as many
+times as it was protected. It is an error to unprotect an object more
+times than it has been protected. Returns the SCM object it was
+passed.
address@hidden deftypefn
+
address@hidden {C Function} SCM scm_gc_unprotect_object (SCM @var{obj})
+Unprotects an object from the garbage collector which was protected by
address@hidden Returns the SCM object it was passed.
address@hidden deftypefn
+
address@hidden {C Function} SCM scm_permanent_object (SCM @var{obj})
+Similar to @code{scm_gc_protect_object} in that it causes the
+collector to always mark the object, except that it should not be
+nested (only call @code{scm_permanent_object} on an object once), and
+it has no corresponding unpermanent function. Once an object is
+declared permanent, it will never be freed. Returns the SCM object it
+was passed.
address@hidden deftypefn
+
address@hidden A Common Mistake In Allocating Smobs
 @subsection A Common Mistake In Allocating Smobs
 
 When constructing new objects, you must be careful that the garbage




reply via email to

[Prev in Thread] Current Thread [Next in Thread]