[zeromq-dev] [PATCH] Custom zmq_msg_t allocator

Martin Sustrik sustrik at 250bpm.com
Thu Jan 20 08:16:50 CET 2011


Hi Douglas,

>> Why not use the existing zmq_msg_init_data() function to get the
>> desired functionality? It allows you to wrap pre-allocated buffer
>> into a message. It also allows you to specify the deallocation
>> function.
>>
>> So using the custom allocator would look something like this:
>>
>> void *buff = my_alloc (1000); ... zmq_msg_t msg; zmq_msg_init_data
>> (buff, 1000, my_free); ...
>
> That's what I tried at first; it lets you allocate the buffer that
> contains the message content.  But there's still a malloc call inside
> of zmq_msg_init_data that allocates space for the zmq::msg_content_t
> bookkeeping struct.  Without this patch, that struct is always
> managed with malloc/free.

Right.

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?

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.

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.

Martin



More information about the zeromq-dev mailing list