[grr, mutt: i keep pressing 'r' instead of 'g', it replies-to -sender not to all, grr. luke, the ex-pine-user]
----- Forwarded message from Luke Kenneth Casson Leighton <[EMAIL PROTECTED]> ----- Date: Wed, 30 May 2001 13:56:49 +0200 From: Luke Kenneth Casson Leighton <[EMAIL PROTECTED]> To: Sander Striker <[EMAIL PROTECTED]> Subject: Re: Catch 22 User-Agent: Mutt/1.2.4i In-Reply-To: <[EMAIL PROTECTED]>; from [EMAIL PROTECTED] on Wed, May 30, 2001 at 01:46:12PM +0200 > > the future implementation order should be: > > > > dynamic loading -> ??? a static, non-dynamic pool-based memory-thing? > > pools -> sms > > sms -> direct memory access > > > > there is nothing to stop you having the 'default' sms structure > > from always being there, such that code that performs > > initialisation, pre-dynamic-loading blah blah all still works > > and you don't have to change any existing code. > > > > what you think? > > Well, the best way would be turning pools into sms. Then #define that's what i kinda assumed would be advocated. > all the pool functions to actually be sms functions. means that things like guaranteed destruction-order also have to be in there, etc. [cf: the apr_pool_join discussion] if _that_ happens, sms pretty much just turns _into_ pools, only stackable. which i had hoped wouldn't happen. i'd like the sms API and principles to be kept simple: simple enough so that it's easy to implement to it and also easy to use and understand. however, if apr_sms_pool can be implemented such that it relies on functionality in sms that is currently embedded into apr_pool [e.g. the destroy stuff], i'd be happy. > I don't know how this will be received. I'm currently talking with > David about this. Maybe we can implement the apr_sms_pool stuff > and when we have it, hit the list with it. Don't know yet. i think that will be a very good way to test the principles / code. ['oh, you're trapped in a pool, are you? need any help? yes? ok, well, there's a cable, here. i'm a bit worried about the sparks flying off the end of it, but other than _that_ it looks pretty soundly tethered...'] > I want to avoid more layers of indirection, because in the final > product they are simply not needed. > ack. more layers, less speed. luke ----- End forwarded message -----
