There is no pleasing some people is there?? Here I go with an explanation of why I made the change...
At present pools are a specific implementation of memory management. In time we hope to get sms to a point where we can replace pools with an sms module that is better. When we get there, it won't matter that we have pools in the sms code as when we replace the pools we'll have to go through and change all the apr code. So at present have locks -> apr_pool_t sms -> locks -> apr_pool_t When we're done we'll have locks -> apr_sms_t sms -> locks -> apr_sms_t So personally I don't see the problem and thus I made the change! I guess maybe it's because people keep saying that we're going to change the pools to use sms. Why? To get the maximum flexibility we'll need to use sms throughout so while we may have apr_pstrdup(apr_pool_t *pool, char *str) we'll end up with apr_pstrdup(apr_sms_t *mem_sys, char *str) That's what I'm aiming at and that's why I keep saying that we won't get to this point until we've released apache. I mean if we had a really kick ass sms module today that we'd tested to destruction then it'd almost be worth making the change, but we're not there yet and won't be for a while. When we do make the change we'll just make an apr_pool_t == apr_sms_t so we ease the job we'll make for our client apps. Now that's all in the future and is where I think we'll end up, but until then we need to be able to use apr from within the memory code. the addition of a pool isn't a big deal really - view it as another type of sms - after all it is a memory system isn't it? We've done it before when we went from context => pool so it's not a huge problem but we need to wait until a release. As for locking, well the logical level for locking to be implemented is in the sms module. Look at the standard module. malloc should be thread safe so no locking should be required, hence we don't have any. In a tracking system we can't guarantee that so we lock. In a system that dumps the memory we'd want to lock around the routine that writes to the file as we wrote correctly. However, it's really a choice that should be made at sms level. Does that make more sense? I'm not sure how many modules we'll end up with and there's nothing to stop platform specific modules being written. It's even possible we'll have specialist modules for certain specialist purposes. That's one of the reasons why I still think it'd be interesting to have dynamic loading of modules so that people can ship binary apache modules and their own specialist memory modules as well. Just a wild notion :) So, do I still hear -1's for the pool in sms approach? david > > On Wed, Jun 06, 2001 at 06:12:17PM -0000, [EMAIL PROTECTED] wrote: > > > - add an apr_pool_t to the sms structure > > > > -1 (non-veto, but awfully close). Uh, why are we doing this? > > I thought that a pool would be defined in terms of a sms (not now, but > > at some point). This would not allow that to happen. > > I'm still not entirely sold on the fact that sms needs locks. I think > > the locks can be handled at a higher level than sms (i.e. a pool). > > I was thinking the exact same thing, actually... > > --Cliff
