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 05:36:53 GMT
> From: Greg Stein []
> Sent: Thursday, June 01, 2000 4:07 PM
> I'm with Ryan on this. The ap_shm_*() functions should be 
> implemented on all platforms, in all configurations.
> APR_HAS_SHARED_MEMORY is available at compile-time to let you 
> know that ap_shm_init() is going to return APR_ENOTIMPL. Of 
> course, you can also do a runtime test.

I can live with this, throughout apr, although I think we need
to be VERY clear where the feature set boundries lie, and plan
out what points can fail.  The obvious statement, if ap_grp_x
returns APR_ENOTIMPL, then ap_grp_y MUST return APR_ENOTIMPL.
Now what about subsets/supersets :-)

But I'm getting past myself, and have been trying to avoid
the two ongoing streams of consiousness.  I'm simply trying to
implement shmem on Win32, not that we need it or want it :-)

I think it is a different thing to build in the feature set
into APR than to require it under an MPM or other module.
I like the idea of the MPM 'emulating' shared memory for
thread-only storage, since the code is written _ONCE_ and if
it is working under true shmem, it _will_ work under the
MPM's simple ap_pmalloc/ap_pfree wrappers.

That's all I'm piping in... feel free to go return to your
regularly scheduled debates :-)

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.

Of course, this implies you may NEVER have a pointer x in any
shm_alloc'ed structure in the conventional sense.  First, if
you point at the int y in the same shm, you will find that the
address of y jumped in process 2.  You CAN use the relative 
offset of y from x to store the pointer, and that offset will
remain the same.

Worse, if you aren't paying attention, and allocate pointer x
in the shm_alloc'ed structure to point at y, but y is sitting
in ANOTHER shm_init'ed pool, you cannot point, you cannot take
a relative address from x to y.  You can only take the relative
address from the offset of the second shm_alloc'ed pool.

I ask because I'm afraid I already know the answer.  If we assume
a true absolute address across processes, it will be an 80+ hour 
(possibly 200+ hour) investment on someone's part to force 
allocations to occur in common open 'slots' between the processes.
I can think of 15 ways to accomplish this under WinNT, not one of 
them is simple.  9x is trivial.

That's way outside of my scope of personal interest in the Apache
project into a direction that doesn't professionally excite me.
If I'm plesantly suprized by the answer, the solution is trivial,
and I'll hack out an implementation over the next week.


View raw message