13.09.2017, 04:40, "Ed Leaver" <ewlea...@comcast.net>: > What??? You mean there's actually a reason people aren't knocking the doors > down over these things? =-O > > A few months ago I was handed a C++ Coding Standard that deigned to prohibit > any further heap allocation after program initialization. It was originally > intended for a hard real-time system; I racked my feeble mind trying to > ascertain how it could possibly apply to our particular project, and finally > suggested -- much as yourself -- that if memory allocation were felt to be a > legitimate concern, there were hooks enough described in man 5 proc to settle > the issue one way or another. > > Then tactfully suggested a more appropriate standard. Tactfully enough that > the suggestion was accepted. > > I ran across TCMalloc in the process. It sounds Really Neat -- but it wasn't > clear why it's Really Neat properties hadn't already been incorporated into > the standard kernel allocator. Is why I asked.
Don't confuse kernel allocator with libc (malloc) allocator. > > Thanks! > > On 09/12/2017 08:43 AM, Thiago Macieira wrote: >> On Monday, 11 September 2017 17:45:01 PDT Ed Leaver wrote: >>> Have any of you experience with jemalloc or TCMalloc? >>> http://goog-perftools.sourceforge.net/doc/tcmalloc.html >> >> Yes. I don't remember which of the two allocators or the details, but I >> remember one of them had a huge thread-safety problem and would corrupt >> itself. Use at your own risk. I will close any bug reports filed if you >> change malloc. > , > > _______________________________________________ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Regards, Konstantin _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
