Hello, First of all, welcome to the community! Sounds like you have a very interesting use case :-)
So there is precedent for using some sort of a custom allocator, although it does not go as far as your requirements: https://github.com/zeromq/czmq/blob/master/include/czmq_prelude.h#L528 So no objections in principle I think. Regarding what can get merged and what can't, we use the C4 process as defined here: https://rfc.zeromq.org/spec:42/C4/ Basically any correct patch that doesn't break (too much) stuff can be accepted :-) I would recommend, following C4, to start sending PRs as soon as you can, with small changes. We have a DRAFT api process, where new stuff is hidden behind a --enable-drafts configure call. I would recommend making as much as possible of this new feature hidden behind the flag, as to avoid disrupting existing users (we know many users build straight from the master branch head). For example, and it's up to you so it's just a suggestion of course, you could start by changing all the mallocs to a common function sort of like czmq does, which without --enable-drafts is just an inline static that calls malloc. And then implement the logic, public and private as draft (this way you can change the public interface as much as you want until it's table). Then we can iterate from that. Again it's entirely up to you. But we've used this model in the past year to successfully introduce big changes without major disruption (eg: new sockets, new poller, etc). On Mon, 2016-11-28 at 10:40 +0200, Petteri Salo wrote: > Hello, > > Let me first do a little introduction as I'm new to this list. I'm a > software engineer with 15+ years of experience working on games at a > company called Remedy Entertainment Ltd. We've done games for PC, and > various games consoles over the years. Most recently we did Quantum Break > for Xbox One. > > I've now been tasked with evaluating ZeroMQ. One important feature of any > library we use in games is the ability to hook all memory allocations - > this is to allow the use of custom memory allocators and/or for tracking > when and where memory is allocated. > > I've searched the libzmq source code and there is about 150 uses of new, > malloc, realloc , etc. > > If we were to adopt libzmq we'd like to put in allocation hooks and that > work would then be something that we'd like to contribute back to the > project. Having those hooks in the main repository would then make it > easier for us to adopt future changes to the library. > > So, my question is would this kind of change be something that would be > accepted? Of course assuming that coding conventions, proper way of > submitting the patch etc. are followed. I do realize that one would want to > see the actual code before accepting. I'm interested in the principle of > accepting a change such as this, since it would introduce a new "rule" for > working ión libzmq source code : "All allocations shall go through an > allocation hook." > > Best Regards, > > Petteri Salo > _______________________________________________ > zeromq-dev mailing list > zeromq-dev@lists.zeromq.org > http://lists.zeromq.org/mailman/listinfo/zeromq-dev
signature.asc
Description: This is a digitally signed message part
_______________________________________________ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
