>>> 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. >> >> This is not possible since we want to be able to set defaults in the >> framework. With a const struct we are not able to do this. > > Why not? If the sms module doesn't feel like implementing its own edition > of one of the functions, it just sets the function pointer in its const > struct to point to the default function. Various bucket types do this > sort of thing all the time.
Granted. That would be an option. I would however suggest to shove this to the backburner until sms has matured a bit more. Until then I like the idea of only changing the reference to a default function in one place. :) > > And, no, it will not prevent these sort of problems. The framework has > > to be able to do some allocating from the sms. In apr_sms_init() the > > sms hasn't been initialized yet. Hence the need for a > apr_sms_post_init() > > function. > > I won't argue against apr_sms_post_init() too loudly. > > What I was imagining, though, was something along the lines of the > apr_sms_foo_create() function passing a pointer to its static "type" > structure into apr_sms_init(). So then apr_sms_init() could set the type > pointer in the apr_sms_t and actually call apr_sms_malloc() if it needed, > calling back into the module via the type structure. That might be a > stretch, I don't know. Ah, that is what you meant... Well, if we are going to do that, we also need to pass in the size of the specific sms structure (ie. sizeof(blocks_sms)). And then, you'd still have the same problem. You may have the functions that are required to do the allocations, but the sms structure (which holds the accounting information for a specific sms) has not yet been initialized in apr_sms_init(). > --Cliff Sander
