Hi all, >> The memory allocator should be extensible (think of an allocator >> strategy);
I see there's interest in this feature, so let's figure out how to implement it. Some notes: 1. If tcmalloc et al are brittle, do we understand why is it so? Is it an inherent problem or just a lame implementation? 2. Douglas' patch stores the pointer to allocator function in a global variable. That breaks the model of separate contexts (i.e. that several instances of 0mq can exist in a single process without misinteracting with each other). We have to think of something more resilient. 3. There are at least two use cases here. AFAIU, Douglas want to custom-allocate the message bodies while Chunk want to custom-allocate everything. We should think a bit more about whether one use case subsumes the other or whether they are two separate use cases with two separate solutions. 4. As a side note: Chuck, given the latest experiments we've done, it doesn't look like the fragmentation of the heap is the problem. Recall that all the chunks in question were either 8kB or 12kB long, which is a multiply of page size. I still suspect that glibc just don't return the allocated memory back to the system... if that is so, no custom user-space allocator is going to help. Martin _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
