httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <>
Subject RE: cvs commit: apache-2.0/src/modules/standard mod_auth_digest.c
Date Fri, 02 Jun 2000 18:58:29 GMT
> From: []
> Sent: Friday, June 02, 2000 11:22 AM
> > > I'm with Ryan on this. The ap_shm_*() functions should be 
> > > implemented on all platforms, in all configurations.
> It's amazing, but that's not what I meant.  If you go back to 
> my original note about all of this, I simply pointed out that 
> we had made a design decision to get rid of all of these stub 
> functions from APR only to have them put back into functions.

Sorry, didn't grok you (unusual, that :-)

> The solution that I like best is to have the feature macro 
> which the core
> uses to implement a server_wide allocation function, using 
> either palloc
> or malloc or ap_shm_malloc depending on the context and MPM.

I don't believe palloc/malloc map well to shm.  But show us
otherwise if you like.

> > But I have one question about ap_shm_ functions... do we have
> > any implicit/explicit assumption that the memory in process A
> > is at the same physical address as process B?  This is a HUGE
> > question under Win32, and probably other hybrid kernels.
> No, that assumption should never be made, because it simply 
> isn't valid in most shared memory implementations.  I believe 
> Apache makes that assumption (althought I could be wrong).  
> I am 99.999% sure that APR makes no such assumption.

Yes, but it's not APR that does anything with the shm, other than
expose it :-)  Sounds like this will be doable in Win32 after all.

I guess if that's the case, I'd like to see us change the args or
return type (typedefed to void *) to make this explicitly clear,
perhaps have the shm_open return a base pointer and shm_malloc
and shm_calloc return an offset type to that base.

View raw message