Each program can be linked with a separate malloc implementation if the user so desires. Libraries don't need to be aware which implementation it is. Different malloc implementation can be even substituted at run time on platforms with dynamic linking support (LD_PRELOAD etc).
On Mon, Nov 28, 2016 at 11:39 AM, Jens Auer <jens.a...@betaversion.net> wrote: > Hi, > > > > yes and no. If you overwrite it globally at compute-time every program on > the system has to use your custom implementation. So if you deliver your > ZeroMQ library with your program it will work, but what if my program wants > a different custom allocator? > > > > Cheers, > > Jens > > > > *Von:* zeromq-dev [mailto:zeromq-dev-boun...@lists.zeromq.org] *Im > Auftrag von *Max Kozlovsky > *Gesendet:* Montag, 28. November 2016 20:36 > *An:* ZeroMQ development list > *Betreff:* Re: [zeromq-dev] On hooking memory allocations > > > > Hi, > > > > Would not globally overwriting malloc/free with the custom implementation > achieve the desired behavior (instead of providing hooks for installing > malloc overrides in each and every library)? > > > > Max > > > > On Mon, Nov 28, 2016 at 5:08 AM, Auer, Jens <jens.a...@cgi.com> wrote: > > Hi, > > I don't see a big problem with the C API except that C doesn't support > overloads. So if the function has a new name, e.g. > zmq_ctx_new_with_allocator, everything stays plain C. The default instance > would be a > > static void* malloc_(size_t n, void*) {return malloc(n);} > static void free_(void* ptr, size_t n, void*) {free(ptr);} > > allocator_t alloc{ > NULL, > malloc_, > free_ > }; > > context_t then stores the member and gets methods to forward memory > allocations to the function pointers, passing the hint pointer as an > additional argument. > > In my C++ code, I can then use an allocator > static void* allocate(size_t n, void* obj) {return > static_cast<std::allocator<char>>(obj)->allocate(n); } > static void free_(void* ptr, size_t n, void*obj) { > static_cast<std::allocator<char>>(obj)->deallocate(ptr, n); } > > std::allocator<char> a; > allocator_t zmqAlloc{ > &a, > allocate, > free_ > }; > > void* ctx = zmq_ctx_new_with_allocator(&zmqAlloc); > > I think this should work? > > Best wishes, > Jens > > -- > Dr. Jens Auer | CGI | Software Engineer > CGI Deutschland Ltd. & Co. KG > Rheinstraße 95 | 64295 Darmstadt | Germany > T: +49 6151 36860 154 > jens.a...@cgi.com > Unsere Pflichtangaben gemäß § 35a GmbHG / §§ 161, 125a HGB finden Sie > unter de.cgi.com/pflichtangaben. > > CONFIDENTIALITY NOTICE: Proprietary/Confidential information belonging to > CGI Group Inc. and its affiliates may be contained in this message. If you > are not a recipient indicated or intended in this message (or responsible > for delivery of this message to such person), or you think for any reason > that this message may have been addressed to you in error, you may not use > or copy or deliver this message to anyone else. In such case, you should > destroy this message and are asked to notify the sender by reply e-mail. > > > -----Original Message----- > > From: zeromq-dev [mailto:zeromq-dev-boun...@lists.zeromq.org] On Behalf > Of > > Luca Boccassi > > Sent: 28 November 2016 12:30 > > To: ZeroMQ development list > > Subject: Re: [zeromq-dev] On hooking memory allocations > > > > That would work for an internal API, but given we expose a C API > unfortunately I > > don't think that would work as a public API :-( And I think for this use > case they > > would require a public API. > > > > As an external API, a new zmq_ctx_set that takes a callback would have > been ideal, > > but it only takes int. So perhaps a new zmq_ctx_set_allocator that takes > a callback > > pointer would be the next best. > > > > An alternative would be to have a system similar to what we use for the > poll > > implementation (epoll kqueue select etc), but this would be a build-time > option, > > and the implementation would have to be checked in, which I don't think > is an > > option for this case, right? > > > > On Mon, 2016-11-28 at 10:51 +0000, Auer, Jens wrote: > > > Hi, > > > > > > I am just a user, but I would love to see this change. I have thinking > > > about this and I would like to be able to pass a C++ allocator object > > > to ZeroMQ, so a simple function hook is not enough. My idea is to > > > define a struct in the interface > > > > > > struct allocator_t > > > { > > > void* hint; > > > void* (allocate)(size_t, void*); > > > void (deallocate)(void*, size_t, void*); }; > > > > > > and store this in the context object. Since I don't think that this > should be > > changed during runtime, I would create a new zmq_ctx_new overload which > takes a > > parameter of type allocator_t. The default value would be to call > malloc/free. > > > > > > Cheers, > > > Jens > > > > > > -- > > > Jens Auer | CGI | Software-Engineer > > > CGI (Germany) GmbH & Co. KG > > > Rheinstraße 95 | 64295 Darmstadt | Germany > > > T: +49 6151 36860 154 > > > jens.a...@cgi.com<mailto:jens.a...@cgi.com> > > > Unsere Pflichtangaben gemäß § 35a GmbHG / §§ 161, 125a HGB finden Sie > unter > > de.cgi.com/pflichtangaben<http://de.cgi.com/pflichtangaben>. > > > > > > CONFIDENTIALITY NOTICE: Proprietary/Confidential information belonging > to CGI > > Group Inc. and its affiliates may be contained in this message. If you > are not a > > recipient indicated or intended in this message (or responsible for > delivery of this > > message to such person), or you think for any reason that this message > may have > > been addressed to you in error, you may not use or copy or deliver this > message to > > anyone else. In such case, you should destroy this message and are asked > to notify > > the sender by reply e-mail. > > > ________________________________ > > > Von: zeromq-dev [zeromq-dev-boun...@lists.zeromq.org]" im Auftrag von > > > "Petteri Salo [petteri.s...@gmail.com] > > > Gesendet: Montag, 28. November 2016 09:40 > > > An: zeromq-dev@lists.zeromq.org > > > Betreff: [zeromq-dev] On hooking memory allocations > > > > > > 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 > > > > _______________________________________________ > zeromq-dev mailing list > zeromq-dev@lists.zeromq.org > http://lists.zeromq.org/mailman/listinfo/zeromq-dev > > > ------------------------------ > > E-Mail ist virenfrei. > Von AVG überprüft - www.avg.com > Version: 2016.0.7924 / Virendatenbank: 4728/13496 - Ausgabedatum: > 28.11.2016 > > _______________________________________________ > zeromq-dev mailing list > zeromq-dev@lists.zeromq.org > http://lists.zeromq.org/mailman/listinfo/zeromq-dev >
_______________________________________________ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
