[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