[email protected] said: > On Fri, Mar 25, 2011 at 7:14 AM, Martin Sustrik <[email protected]> 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 _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
