diff --git a/doc/devel/draw/AllocationCluster.svg b/doc/devel/draw/AllocationCluster.svg index b2e91a268..968a15311 100644 --- a/doc/devel/draw/AllocationCluster.svg +++ b/doc/devel/draw/AllocationCluster.svg @@ -6,7 +6,6 @@ xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:svg="http://www.w3.org/2000/svg" xmlns="http://www.w3.org/2000/svg" - xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd" xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape" width="800" @@ -25,9 +24,9 @@ borderopacity="1.0" inkscape:pageopacity="0.0" inkscape:pageshadow="2" - inkscape:zoom="1" - inkscape:cx="280.90499" - inkscape:cy="352.82916" + inkscape:zoom="2.8284271" + inkscape:cx="311.29718" + inkscape:cy="408.68554" inkscape:document-units="px" inkscape:current-layer="svg2" inkscape:window-width="1485" @@ -54,186 +53,6 @@ guidetolerance="5" /> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - <T2> raw storage -
+
Memory management facility for the low-level model (render nodes network). The model is organised into temporal segments, which are considered to be structurally constant and uniform. The objects within each segment are strongly interconnected, and thus each segment is being built in a single build process and is replaced or released as a whole. __~AllocationCluster__ implements memory management to support this usage pattern. He owns a number of object families of various types.[>img[draw/AllocationCluster.png]]
 * [[processing nodes|ProcNode]] &mdash; probably with several subclasses (?)
 * [[wiring descriptors|WiringDescriptor]]
@@ -523,7 +523,7 @@ SiteUrl
To Each of those families we can expect an initially undetermined (but rather large) number of individual objects, which can be expected to be allocated within a short timespan and which are to be released cleanly on destruction of the AllocationCluster. ''Problem of calling the dtors'' -Even if the low-level memory manager(s) may use raw storage, we require that the allocated objects desctuctores be called. This means keeping track at least of the number of objects acllocated (without wasting too much memory for bookeeping). Besides, as the objects are expected to be interconnected, it may be dangerous to destroy a given family of objects while another family of objects may rely on the former in its destructor. //If we happen do get into this situation,// we need to define a priority order on the types and assure the destruction sequence is respected. +Even if the low-level memory manager(s) may use raw storage, we require that the allocated object's destructors be called. This means keeping track at least of the number of objects allocated (without wasting too much memory for bookkeeping). Besides, as the objects are expected to be interconnected, it may be dangerous to destroy a given family of objects while another family of objects may rely on the former in its destructor. //If we happen do get into this situation,// we need to define a priority order on the types and assure the destruction sequence is respected. &rarr; see MemoryManagement