apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Cliff Woolley <cliffwool...@yahoo.com>
Subject RE: cvs commit: apr/memory/unix apr_sms.c apr_sms_blocks.c apr_sms_std.c apr_sms_tracking.c
Date Fri, 29 Jun 2001 22:48:55 GMT
On Sat, 30 Jun 2001, Sander Striker wrote:

> > 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.

> 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.


   Cliff Woolley
   Charlottesville, VA

View raw message