diff options
author | Andy Wingo <wingo@pobox.com> | 2014-04-28 18:00:05 +0200 |
---|---|---|
committer | Andy Wingo <wingo@pobox.com> | 2014-04-28 18:00:05 +0200 |
commit | 4338f2f91e1dd63a40384077d091295d90047926 (patch) | |
tree | 78bb149f49b6c58ea2757a0c41e6c6bc13ac1f38 /doc/ref/api-memory.texi | |
parent | b1812a6ce43f2eab5542f14e4989c5ecc31f9a94 (diff) | |
download | guile-4338f2f91e1dd63a40384077d091295d90047926.tar.gz |
Prefer foreign objects over smobs in manual
* doc/ref/api-memory.texi (Memory Blocks): Recommend against
scm_gc_free. Refer to foreign objects instead of smobs. Remove
discussion of scm_must_malloc et al.
* doc/ref/guile.texi (API Reference): Rename SMOB menu item.
* doc/ref/libguile-snarf.texi (Function Snarfing): Update example to not
refer to smobs.
* doc/ref/tools.texi (How guile-snarf works): Likewise.
Diffstat (limited to 'doc/ref/api-memory.texi')
-rw-r--r-- | doc/ref/api-memory.texi | 84 |
1 files changed, 12 insertions, 72 deletions
diff --git a/doc/ref/api-memory.texi b/doc/ref/api-memory.texi index 657f745b4..099d80678 100644 --- a/doc/ref/api-memory.texi +++ b/doc/ref/api-memory.texi @@ -112,15 +112,16 @@ functions for dynamic memory allocation that are integrated into the garbage collector and the error reporting system. Memory blocks that are associated with Scheme objects (for example a -smob) should be allocated with @code{scm_gc_malloc} or +foreign object) should be allocated with @code{scm_gc_malloc} or @code{scm_gc_malloc_pointerless}. These two functions will either return a valid pointer or signal an error. Memory blocks allocated this -way can be freed with @code{scm_gc_free}; however, this is not strictly -needed: memory allocated with @code{scm_gc_malloc} or -@code{scm_gc_malloc_pointerless} is automatically reclaimed when the -garbage collector no longer sees any live reference to it@footnote{In -Guile up to version 1.8, memory allocated with @code{scm_gc_malloc} -@emph{had} to be freed with @code{scm_gc_free}.}. +way may be released explicitly; however, this is not strictly needed, +and we recommend @emph{not} calling @code{scm_gc_free}. All memory +allocated with @code{scm_gc_malloc} or @code{scm_gc_malloc_pointerless} +is automatically reclaimed when the garbage collector no longer sees any +live reference to it@footnote{In Guile up to version 1.8, memory +allocated with @code{scm_gc_malloc} @emph{had} to be freed with +@code{scm_gc_free}.}. Memory allocated with @code{scm_gc_malloc} is scanned for live pointers. This means that if @code{scm_gc_malloc}-allocated memory contains a @@ -204,7 +205,9 @@ size of a reallocated memory block as well. See below for a motivation. @deftypefn {C Function} void scm_gc_free (void *@var{mem}, size_t @var{size}, const char *@var{what}) Explicitly free the memory block pointed to by @var{mem}, which was -previously allocated by one of the above @code{scm_gc} functions. +previously allocated by one of the above @code{scm_gc} functions. This +function is almost always unnecessary, except for codebases that still +need to compile on Guile 1.8. Note that you need to explicitly pass the @var{size} parameter. This is done since it should normally be easy to provide this parameter @@ -225,7 +228,7 @@ often (as appropriate). It is especially important to call this function when large unmanaged allocations, like images, may be freed by small Scheme allocations, like -SMOBs. +foreign objects. @end deftypefn @@ -248,69 +251,6 @@ preprocessor macro was defined when Guile was compiled. @end deffn -@subsubsection Upgrading from scm_must_malloc et al. - -Version 1.6 of Guile and earlier did not have the functions from the -previous section. In their place, it had the functions -@code{scm_must_malloc}, @code{scm_must_realloc} and -@code{scm_must_free}. This section explains why we want you to stop -using them, and how to do this. - -@findex scm_must_malloc -@findex scm_must_realloc -@findex scm_must_calloc -@findex scm_must_free -The functions @code{scm_must_malloc} and @code{scm_must_realloc} -behaved like @code{scm_gc_malloc} and @code{scm_gc_realloc} do now, -respectively. They would inform the GC about the newly allocated -memory via the internal equivalent of -@code{scm_gc_register_allocation}. However, -@code{scm_must_free} did not unregister the memory it was about to -free. The usual way to unregister memory was to return its size from -a smob free function. - -This disconnectedness of the actual freeing of memory and reporting -this to the GC proved to be bad in practice. It was easy to make -mistakes and report the wrong size because allocating and freeing was -not done with symmetric code, and because it is cumbersome to compute -the total size of nested data structures that were freed with multiple -calls to @code{scm_must_free}. Additionally, there was no equivalent -to @code{scm_malloc}, and it was tempting to just use -@code{scm_must_malloc} and never to tell the GC that the memory has -been freed. - -The effect was that the internal statistics kept by the GC drifted out -of sync with reality and could even overflow in long running programs. -When this happened, the result was a dramatic increase in (senseless) -GC activity which would effectively stop the program dead. - -@findex scm_done_malloc -@findex scm_done_free -The functions @code{scm_done_malloc} and @code{scm_done_free} were -introduced to help restore balance to the force, but existing bugs did -not magically disappear, of course. - -Therefore we decided to force everybody to review their code by -deprecating the existing functions and introducing new ones in their -place that are hopefully easier to use correctly. - -For every use of @code{scm_must_malloc} you need to decide whether to -use @code{scm_malloc} or @code{scm_gc_malloc} in its place. When the -memory block is not part of a smob or some other Scheme object whose -lifetime is ultimately managed by the garbage collector, use -@code{scm_malloc} and @code{free}. When it is part of a smob, use -@code{scm_gc_malloc} and change the smob free function to use -@code{scm_gc_free} instead of @code{scm_must_free} or @code{free} and -make it return zero. - -The important thing is to always pair @code{scm_malloc} with -@code{free}; and to always pair @code{scm_gc_malloc} with -@code{scm_gc_free}. - -The same reasoning applies to @code{scm_must_realloc} and -@code{scm_realloc} versus @code{scm_gc_realloc}. - - @node Weak References @subsection Weak References |