The problem with the static structure is that we loose the ability to have default allocators available and would have made no difference at all in this case as the lock creation is a different problem. We'd still do the creation as
- calloc the memory - do the first part of the initialisation - add the functions - check what we have - do post init stuff Bear in mind that some of the things we allocate (pool and lock) can't be static so we'll still some dynamic allocations. The problem with the locks is that if a pool == sms then when we try to create the lock using the current, partially formed sms, then we segfault. Doing it at a later phase (post_init) resolves this problem. I have no objection to static structures but not sure they really gain us very much and this is really an optimisation isn't it? :) It's your time however! david > On 29 Jun 2001 [EMAIL PROTECTED] wrote: > > > Log: > > We add another phase to the sms creation/initialisation that > > allows us to make calls that can/could use the sms and if we > > haven't finished initialising it, it'll segafult due to the lack > > of function pointers. > > > > This came up when trying to get pools running as sms :) > > I'll reiterate my desire to see us use a static const struct for the > function pointers in sms (a la the apr_bucket_type_t). Not only would it > make it slightly faster to create an sms, it could help avoid these sorts > of problems. > > I know, I know... if I want it done, I should just patch the damn thing. > I'll try to get to it this weekend. =-) > > --Cliff > > -------------------------------------------------------------- > Cliff Woolley > [EMAIL PROTECTED] > Charlottesville, VA > > >
