On Wed, Jul 11, 2001 at 04:32:54PM +0200, Sander Striker wrote: > > > When one of us gets a chance, we can implement the child_malloc path in > > > trivial. That should remove most of the current complaints about SMS. > > > > so, you want to add apr_sms_child_malloc etc. which makes > > SMS a non-trivial API, which is one solution to the problem, > > and the other solution is to write a better sms than > > apr_sms_trivial. > > > > one solution makes the SMS api quite complex. > > > > the other keeps it simple. > > The exported API to userland will not change (see below). ack. okay. makes me happier.
> > i know that there have been message flying back/forth. > > i don't understand them. > > > > please do me a favour: could you write up a clear explanation > > of exactly what the purpose of apr_sms_child_malloc is? > > Ah, ok. The implementation of an sms calls apr_sms_child_malloc > instead of apr_sms_malloc when it wants memory from its parent. ... okay... why? > The same goes for calloc and free. These xxx_child_xxx functions > will _not_ be exported outside the SMS code space. > The xxx_child_xxx functions can be optionally present in an > sms to make a distinction between a user asking memory or a > child sms requesting memory. this is the bit that makes me nervous. it makes sms more complex to program to, to use, and to understand. how are you going to keep _users_ from _not_ using apr_sms_child_xxx and friends? > By default the framework will > use the malloc_fn, if a child_malloc_fn is present it will > use this. This allows us to handle child sms allocations > differently, hereby for example not letting the trivial > sms add the extra 4096 bytes on the alloc each time the > child requests 8192 bytes. ... urrr... not being funny or anything, but what is a trivial mallocator doing adding an extra 4096 bytes in the _first_ place? doesn't sound very trivial to me! trivial to me says 'this is really simple. it works, it probably stinks, we don't care: it proves the point, it's proof-of-concept, you can get to grips with it in under 5 minutes, and if you want more complex stuff that Does A Better Job, well... tough! go use or write something else that isn't "trivial"'. ... but leaving that issue aside, _why_ is the trivial_malloc 'rounding up' the sizes to the nearest min_block size? that implies that you are second-guessing the parent mallocator's ability to manage memory, and maybe even screwing _up_ the parent mallocator's ability to manage memory! in fact, that's exactly what's happening! we _know_ that malloc and free are pretty efficient on most operating systems. so why not rely on that efficiency instead of trying to second-guess it and round-up the malloc-block sizes? btw, i'm quite happy to be told that i really don't get this, and to have things [im]patiently explained to me so i shut up :) > > because it's very unclear [and i helped _design_ SMS, remember?] > > and if it's unclear, i really don't think it's a good idea to > > put it in, especially if there are other solutions. > > > > basically, apr_sms_child_malloc is giving me bad vibes - warning > > alarm bells are ringing: that's the best way i can put it. > > Well, for now this is the best solution to solve the problems seen > in apache _without_ modifying the apache codebase. It is a way to > allow stacking of advanced memory systems in a more acceptable > manner when it comes to performance/waste trade-off. surely there are better ways to do this that can be investigated _before_ expanding the SMS API into a more complex system? all best, luke
