apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Reid" <dr...@jetnet.co.uk>
Subject Re: cvs commit: apr/memory/unix apr_sms.c apr_sms_blocks.c apr_sms_std.capr_sms_tracking.c
Date Fri, 29 Jun 2001 21:46:21 GMT
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


> 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.
> 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
>    cliffwoolley@yahoo.com
>    Charlottesville, VA

View raw message