apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sander Striker" <stri...@apache.org>
Subject RE: cvs commit: apr/memory/unix apr_sms.c apr_sms_blocks.c apr_sms_std.c apr_sms_tracking.c
Date Sat, 30 Jun 2001 08:08:28 GMT
>>> 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.
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


View raw message