> The memory allocator should be extensible (think of an allocator strategy); > same thing for the disk swap. What I mean by "strategy" is that it should be > possible to plug one's own implementation of these things (memory allocator, > disk swapper). Both should have default internal implementations.
Awhile back I submitted a patch to allow a custom memory allocator for zmq_msg_t objects. It wasn't pervasive throughout the entire library, though. To extend it to the rest of 0mq, you could store pointers to the allocator and swapper implementations inside of the context object. But you'd need to change the zmq_msg_t API to take in a context object, since those functions would need access to the allocator. The patch wasn't merged into mainline, partly because several people pointed out that you can use a malloc replacement library (tcmalloc, jemalloc, etc) instead. Then you still call malloc/free/etc in the 0mq code. I experimented with this a bit, and it actually seemed pretty brittle, at least on Mac OS X — it seems like something allocates memory using the system malloc before loading in the malloc replacement, which causes problems when that memory is freed at the end. I didn't really follow up on this (other things were more urgent), but my hunch is that an actual allocation/swapper API would be less troublesome. –doug
PGP.sig
Description: This is a digitally signed message part
_______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
