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

Martin Lucina mato at kotelna.sk
Fri Mar 25 11:05:00 CET 2011


m.pales at gmail.com said:
> On Fri, Mar 25, 2011 at 7:14 AM, Martin Sustrik <sustrik at 250bpm.com> wrote:
> 
>     7. We should then find out whether it's possible to overload standard
>     malloc/free in the library in such a way that our implementation is used
>     instead of the implementation provided by C runtime.
> 
> 
> On Solaris, I usually link my application with libumem due to its better
> performance,
> scalability and mainly debugging capabilities. That way all new/delete (malloc/
> free)
> calls are replaced by libumem's implementation.

I've also done this in the past, e.g. for OpenAMQ builds on Solaris, with
great success.

> This approach also works for tcmalloc, jemalloc, mtmalloc, etc.
> 
> Using LD_PRELOAD mechanism is also possible but IMHO it is mainly for
> development to try and see or tests like this:
> http://developers.sun.com/solaris/articles/multiproc/multiproc.html

Precisely, however, at least on Solaris and Linux (and I presume OSX also)
you can link with tcmalloc at build time, thus avoiding use of LD_PRELOAD
at all.

So, normally (sans libtool and all that cruft), you would link an
application as follows:

   cc -o app app.o -lzmq

If instead you do

   cc -o app app.o -lzmq -ltcmalloc

Then bingo, your application will use tcmalloc. No brittleness at all.

Martin, maybe all we need to do is document this prominently in the FAQ? It
is a *much less invasive and complex* solution than adding custom
allocators to 0mq!

The only question remains (as I understand it from the discussion) that at
least some people here are on Windows. I don't know if it's this easy to
get the same result.

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?

-mato



More information about the zeromq-dev mailing list