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

Martin Sustrik sustrik at 250bpm.com
Thu Mar 24 19:04:10 CET 2011


On 03/24/2011 06:07 PM, gonzalo diethelm wrote:

>> 1. If tcmalloc et al are brittle, do we understand why is it so? Is
>> it an inherent problem or just a lame implementation?
>
> I think it is just a case for flexibility. You may want to apply
> different strategies for different programs, or even within the same
> program. For instance, I remember having an allocator under ACE to
> create memory from a shared memory pool in some instances.

This boils down to the use case question afaics. If the alternate 
allocation mechanism is just a performance hack, you want to apply it to 
all the objects allocated in 0mq.

If it has some special properties, like allocating in shmem, then you 
want to apply it only to message bodies.

The two options require different APIs and implemetations.

>> 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.
>
> Perhaps the allocator should be embedded into the context. You could
> even create separate contexts if you wish to have different
> allocators.

The problem is that message has no idea what context it belongs to.

> Maybe you could provide two args to the allocator when allocating
> memory: the size in bytes and a hint. This hint could be used by the
> allocator to decide upon it: use different memory pools for different
> parts of the program, etc. Then, you could use the allocator for
> everything in ZeroMQ itself and in programs using ZeroMQ, assuming
> ZeroMQ will have a default implementation of the allocator.

Yes, something like this can be used internally to pass context when 
creating a new message body for a message being received.

However, let's figure out how the API should look like and think about 
the implemetation afterwards.

Martin



More information about the zeromq-dev mailing list