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 Fri, 29 Jun 2001 22:23:51 GMT
> On 29 Jun 2001 dreid@apache.org 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.

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.

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.

The situation was this [semi pseudo]:

apr_sms_xxx_create(apr_sms_t **sms, apr_sms_t *parent)
{
    ...
    new_sms = apr_sms_calloc(parent, size_of_this_sms);
    
    apr_sms_init(new_sms);

    ...
}

In the new situation we get:

apr_sms_xxx_create(apr_sms_t **sms, apr_sms_t *parent)
{
    ...
    new_sms = apr_sms_calloc(parent, size_of_this_sms);
    
    apr_sms_init(new_sms);

    ...

    apr_sms_post_init(new_sms);
}

The apr_sms_post_init() can be usefull for more than
one thing. I suggest moving the apr_sms_assert()
call into it, for example.

Sander


Mime
View raw message