docs/src/features.md

changeset 993
b642eca4b956
parent 962
cd418898af5c
child 998
bb196054f3fd
--- a/docs/src/features.md	Tue Nov 26 22:00:03 2024 +0100
+++ b/docs/src/features.md	Tue Nov 26 22:16:27 2024 +0100
@@ -90,12 +90,12 @@
 It also allows you to register destructor functions for the allocated memory, which are automatically called before
 the memory is deallocated.
 Additionally, you may also register _independent_ destructor functions within a pool in case some external library
-allocated memory for you, which should be destroyed together with this pool.
+allocated memory for you, which should be freed together with this pool.
 
 Many UCX features support the use of an allocator.
 The [strings](#string), for instance, provide several functions suffixed with `_a` that allow specifying an allocator.
 You can use this to keep track of the memory occupied by dynamically allocated strings and cleanup everything with
-just a single call to `cxMempoolDestroy()`.
+just a single call to `cxMempoolFree()`.
 
 The following code illustrates this on the example of reading a CSV file into memory. 
 ```C
@@ -145,7 +145,7 @@
         size_t fc = cx_strsplit(lines[i], CX_STR(";"), 3, fields);
         if (fc != 3) {
             fprintf(stderr, "Syntax error in line %zu.\n", i);
-            cxMempoolDestroy(pool);
+            cxMempoolFree(pool);
             return 1;
         }
         CSVData data;
@@ -168,7 +168,7 @@
     }
 
     // cleanup everything, no manual free() needed 
-    cxMempoolDestroy(pool);
+    cxMempoolFree(pool);
 
     return 0;
 } 

mercurial