apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Luke Kenneth Casson Leighton <l...@samba-tng.org>
Subject Re: Catch 22
Date Wed, 30 May 2001 12:17:45 GMT
[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 <lkcl@samba-tng.org> -----

Date: Wed, 30 May 2001 13:56:49 +0200
From: Luke Kenneth Casson Leighton <lkcl@samba-tng.org>
To: Sander Striker <striker@samba-tng.org>
Subject: Re: Catch 22
User-Agent: Mutt/1.2.4i
In-Reply-To: <JLEGKKNELMHCJPNMOKHOEEBBDPAA.striker@samba-tng.org>; from striker@samba-tng.org
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.


----- End forwarded message -----

View raw message