how about a hybrid solution which supports a custom allocator solely for buffer allocation? these are the things that the application knows about; other stuff (especially language stuff like C++'s STL) is too hard to do that way.
On Mar 25, 2011, at 3:37 PM, Martin Pales wrote: > On Fri, Mar 25, 2011 at 8:21 PM, Douglas Creager <[email protected]> > wrote: > > AFAIK, this is only possible on Mac OS X, but in systems like Linux or > > Solaris, an application can only have one allocator. > > Only if you access the allocator through the malloc/free/etc global symbols. > With the custom allocation API that I'm proposing, you access the allocator > through an explicit function pointer, so you have finer (and portable) > control. > > The problem is that libzmq does access the allocator via malloc/free, since > it is in C++ and uses STL. With a custom allocator you could control certain > areas inside libzmq such as internal queues. Replacing all the possible > allocations/deallocations would be quite a challenge. > > Also, usually an application also links other libraries and normally you have > no control over them. The only solution is again to link with a tcmalloc or > similar provided the default allocator is a bottleneck. > > Martin > > _______________________________________________ > zeromq-dev mailing list > [email protected] > http://lists.zeromq.org/mailman/listinfo/zeromq-dev ------------------ Andrew Hume (best -> Telework) +1 623-551-2845 [email protected] (Work) +1 973-236-2014 AT&T Labs - Research; member of USENIX and LOPSA
_______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
