Date: Mon, 26 Dec 2005 10:26:45 -0800 From: Jason Evans <jasone@freebsd.org> To: Max Khon <fjoe@samodelkin.net> Cc: freebsd-current@freebsd.org Subject: Re: New malloc ready, take 42 Message-ID: <B65EC3BB-6A5A-4299-BD86-A7D2AB381941@freebsd.org> In-Reply-To: <20051226101825.GA92082@samodelkin.net> References: <E1E22E2D-A6D5-49CC-9649-C37C50F0443B@freebsd.org> <20051226101825.GA92082@samodelkin.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Dec 26, 2005, at 2:18 AM, Max Khon wrote: > > Do you plan to provide public API for malloc arenas > similar to SGI amalloc(3)? > > http://techpubs.sgi.com/library/tpl/cgi-bin/getdoc.cgi? > coll=0650&db=man&fname=/usr/share/catman/p_man/cat3p/amallinfo.z I hadn't planned to do so. It's not too hard to think of scenarios in which manual management of arenas might be useful, but adding non- standard public APIs to libc is something that I'm reluctant to do unless there is a compelling reason to do so. Arena-specific APIs would work well with jemalloc, but they may not make sense for whatever comes after jemalloc, yet we'd be stuck with supporting the APIs. In fact, if I were making API changes to non-standard libc interfaces, the first thing I'd do would be to remove reallocf(3), or at least rename it to reallocf_np(). Are there compelling use cases you can think of that might sway us toward providing malloc arena APIs? Thanks, Jason
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?B65EC3BB-6A5A-4299-BD86-A7D2AB381941>