[svnbook commit] r2720 - trunk/src/en/book

[cmpilato]

Author: cmpilato
Date: Tue Feb 27 02:20:23 2007
New Revision: 2720

Modified:
   trunk/src/en/book/ch08-embedding-svn.xml

Log:
* src/en/book/ch08-embedding-svn.xml
  Revive a portion of the old Programming With Memory Pools section
  from the 1.2 version of the book as a sidebar.  (Sorta.)


Modified: trunk/src/en/book/ch08-embedding-svn.xml
==============================================================================
--- trunk/src/en/book/ch08-embedding-svn.xml	(original)
+++ trunk/src/en/book/ch08-embedding-svn.xml	Tue Feb 27 02:20:23 2007
@@ -784,6 +784,47 @@
         <function>svn_pool_clear()</function>, and 
         <function>svn_pool_destroy()</function>.</para>
 
+      <sidebar>
+        <title>Programming with Memory Pools</title>
+
+        <para>Almost every developer who has used the C programming
+          language has at some point sighed at the daunting task of
+          managing memory usage.  Allocating enough memory to use,
+          keeping track of those allocations, freeing the memory when
+          you no longer need it—these tasks can be quite
+          complex.  And of course, failure to do those things properly
+          can result in a program that crashes itself, or worse,
+          crashes the computer.</para>
+
+        <para>Higher-level languages, on the other hand, take the job of
+          memory management away from the developer completely.
+          <footnote>
+            <para>Or at least make it something you only toy with when
+              doing extremely tight program optimization.</para>
+          </footnote>
+          Languages like Java and Python use <firstterm>garbage
+          collection</firstterm> principles, allocating memory for
+          objects when needed, and automatically freeing that memory
+          when the object is no longer in use.</para>
+
+        <para>APR provides a middle-ground approach called pool-based
+          memory management.  It allows the developer to control
+          memory usage at a lower resolution—per chunk (or
+          <quote>pool</quote>) of memory, instead of per allocated
+          object.  Rather than using <function>malloc()</function> and
+          friends to allocate enough memory for a given object, you
+          ask APR to allocate the memory from a memory pool.  When
+          you're finished using the objects you've created in the
+          pool, you destroy the pool, effectively de-allocating the
+          memory consumed by the objects you allocated from it.
+          Rather than keeping track of individual objects which need
+          to be de-allocated, your program simply considers the
+          general lifetimes of those objects, and allocates the
+          objects in a pool whose lifetime (the time between the
+          pool's creation and its deletion) matches the object's
+          needs.</para>
+
+      </sidebar>
     </sect2>
 
     <!-- =============================================================== -->