shaba/lvm2
1
0
Fork 0
mirror of git://sourceware.org/git/lvm2.git synced 2025-01-02 01:18:26 +03:00
Code Releases Activity

o Reformat comment and correct typo.

Browse Source
This commit is contained in:
Joe Thornber 2002-01-14 09:59:12 +00:00
parent 1ed34e88aa
commit ea31a9b09c
1 changed files with 22 additions and 29 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

51
lib/mm/pool.h
View File

@ -12,42 +12,35 @@
/*
* The pool allocator is useful when you are going
* to allocate lots of memory, use the memory for
* a bit, and then free the memory in one go. A
* surprising amount of code has this usage
* The pool allocator is useful when you are going to allocate
* lots of memory, use the memory for a bit, and then free the
* memory in one go. A surprising amount of code has this usage
* profile.
*
* You should think of the pool as an infinite,
* contigous chunk of memory. The front of this
* chunk of memory contains allocated objects, the
* second half is free. pool_alloc grabs the next
* 'size' bytes from the free half, in effect
* moving it into the allocated half. This
* operation is very efficient.
* You should think of the pool as an infinite, contiguous chunk
* of memory. The front of this chunk of memory contains
* allocated objects, the second half is free. pool_alloc grabs
* the next 'size' bytes from the free half, in effect moving it
* into the allocated half. This operation is very efficient.
*
* pool_free frees the allocated object *and* all
* objects allocated after it. It is important to
* note this semantic difference from malloc/free.
* This is also extremely efficient, since a
* single pool_free can dispose of a large complex
* object.
* pool_free frees the allocated object *and* all objects
* allocated after it. It is important to note this semantic
* difference from malloc/free. This is also extremely
* efficient, since a single pool_free can dispose of a large
* complex object.
*
* pool_destroy frees all allocated memory.
*
* eg, If you are building a binary tree in your
* program, and know that you are only ever going
* to insert into your tree, and not delete (eg,
* maintaining a symbol table for a compiler).
* You can create yourself a pool, allocate the
* nodes from it, and when the tree becomes
* redundant call pool_destroy (no nasty iterating
* through the tree to free nodes).
* eg, If you are building a binary tree in your program, and
* know that you are only ever going to insert into your tree,
* and not delete (eg, maintaining a symbol table for a
* compiler). You can create yourself a pool, allocate the nodes
* from it, and when the tree becomes redundant call pool_destroy
* (no nasty iterating through the tree to free nodes).
*
* eg, On the other hand if you wanted to
* repeatedly insert and remove objects into the
* tree, you would be better off allocating the
* nodes from a free list; you cannot free a
* eg, On the other hand if you wanted to repeatedly insert and
* remove objects into the tree, you would be better off
* allocating the nodes from a free list; you cannot free a
* single arbitrary node with pool.
*/