I'm writing a multithreaded program which produces a TIN from a point cloud. There's one UI thread, which spawns several worker threads (by default as many as the processor has), each of which works on the same data structure, consisting of points, edges, and triangles, with each triangle having a vector of dots. (For historical reasons, the corners of the triangles are called points, so I call the points in the point cloud dots.) During the conversion, points, edges, and triangles are only added, while dots are moved from one triangle to another, calling shrink_to_fit after the move. Qt also starts some threads, but I'm not concerned with them.
To see how much RAM the program takes when run on a large point cloud, I ran the program, opened a previously saved TIN, cleared it, loaded a point cloud, converted it to a TIN, and did similar things while watching the task's memory allocation. I found it kept memory allocated after clearing the TIN, and loading and converting a point cloud after opening and clearing a TIN resulted in more memory allocated than loading and converting a point cloud in a fresh run of the program. I suspected a big memory leak, but found none. The reason turns out to be that each thread has its own arena. When you open or load a file, worker thread 0 does all the work, so the data structure is built in thread 0's arena. When you convert a point cloud to TIN, the point cloud, which was loaded into thread 0's arena, is moved into six triangles, still in thread 0's arena, then all threads create triangles, each in its own arena, but thread 0's allocation remains greater than the others. On my Linux laptop, the eight arenas are 64 MiB apart. There is no way to let go of freed RAM, except in the main thread's arena. I tried to check this on DragonFly, but instead of showing me each element of a map, the debugger just showed me the root node of the red-black tree. How does DragonFly handle allocation by multithreaded programs? Pierre -- li fi'u vu'u fi'u fi'u du li pa
