[zeromq-dev] Important: backward incompatible changes for 0MQ/3.0!

Andrew Hume andrew at research.att.com
Fri Mar 25 15:17:50 CET 2011

in my experience, custom memory allocators fall into two camps:

1) general memory allocators that effectively replace malloc/realloc/free.
	most are written as drop in replacements as mato outlined.
	some have a slightly API and so are slightly harder.

2) application level allocator. the classical example are fixed-sized buffers
	where free just adds the buffer to a freelist and when you run out,
	you malloc a boatload and add them to teh free list. these normally
	outperform general allocators because they embody use-specific knowledge.

type 2) allocators need support within libzmq -- it can't be done as a dropin replacement.


On Mar 25, 2011, at 4:05 AM, gonzalo diethelm wrote:

>> So, I'd like to ask again: Gonzalo, Douglas, and others here asking for a
>> custom memory allocator: Can you not use the above solution? If so, why
>> not?
> Yes, definitely that is a good and cheap way of improving memory allocation. But from previous experience, having a custom allocator is also great for weird / corner cases (like using shared memory), although you are correct, it is a very invasive change.
> -- 
> Gonzalo Diethelm
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Andrew Hume  (best -> Telework) +1 623-551-2845
andrew at research.att.com  (Work) +1 973-236-2014
AT&T Labs - Research; member of USENIX and LOPSA

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20110325/392e68d2/attachment.htm>

More information about the zeromq-dev mailing list