[zeromq-dev] [PATCH] Custom zmq_msg_t allocator

[Douglas Creager]

I like the tcmalloc suggestion, it sounds like an easier way around the problem.  That wouldn't require any changes at all to zeromq, right?  I'd only do the -ltcmalloc when linking the final application, and not with any of the intervening libraries.  I'll do some quick tests on that to see how it works.

If tcmalloc works as expected, then the patch will no longer be necessary.  But here are the answers to your questions for posterity.

> I think we need some analysis of the use cases first, namely:
> 
> 1. Why do we need to allocate messages using a non-standard allocator? 
> If there's a performance problem with allocation, shouldn't the 
> allocation mechanism be replaced as a whole (say by linking with 
> tcmalloc or somesuch)?
> 
> 2. If there's a valid reason for the above, is it necessary that the 
> custom allocator is specified in runtime instead of in compile-time?

The driver for me was the poor performance of the standard malloc.  I went with a runtime option because I didn't want to have to compile a custom libzmq — and also because I was basically copying the allocator interface from the Lua interpreter!

> As a side note: Note that zmq_init_data() custom allocation mechanism is 
> intended to allow for passing blocks of data allocated by 3rd party 
> libraries that we have no control of rather than trying to provide a 
> message-specific optimised-allocation-algorithm performance boost.

Yep, that's still true with the patch.  In the init_data case, there are two buffers, which are freed differently.  The message content is still freed using the custom function passed into zmq_msg_init_data(), so it still handles 3rd party message buffers.  The additional zmq::msg_content_t buffer is freed using the custom allocator, which is set by the zmq_msg_set_allocator function.

> Another side note: When storing global state, don't use global 
> variables. Global variables tend to work well until the library is 
> linked into the same app twice. Then it just begins to behave strange. 
> Store any global state in the context. That's what the context is there for.

I had used global variables because the zmq_msg functions currently don't take in a context object, and it would be a breaking API change to add an additional parameter.  I figured global variables were the lesser of two evils.  But I hadn't thought of the double-link case.

–doug
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 203 bytes
Desc: This is a digitally signed message part
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20110120/e5250628/attachment.sig>