httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Brian Havard" <bri...@kheldar.apana.org.au>
Subject Re: OS/2 Scoreboard changes
Date Wed, 07 Feb 2001 15:22:36 GMT
On Tue, 6 Feb 2001 16:51:08 -0800 (PST), rbb@covalent.net wrote:

>> For people using the shared memory version of the scoreboard, would it be
>> possible for the MPM to say "add this much space onto the end of the
>> scoreboard entries, so that I can store private stuff in there" ??
>
>You're right where I was last week, when I last thought about this
>problem.  The basic problem, is that MM requires additional space
>everytime we call mm_malloc.  For example, if we call apr_shm_init(1024),
>and then apr_shm_malloc(1024), in reality MM sets up 1024+sizeof(MM) bytes
>of shared memory and then during the mm_malloc call, it uses
>sizeof(MM) bytes for the MM structure, and 1024 bytes for what we asked
>for.
>
>The problem is then that if we do the following, we don't have enough
>memory:
>
>apr_shm_init(1024);
>apr_shm_malloc(512);
>apr_shm_malloc(512);
>
>Again, the shm_init call added sizeof(MM) to the 1024, but it has no idea
>how many times we are going to malloc out of the shared memory.
>
>This is why in the old code, we had a fudge factor, and then we just setup
>two apr_shm_t's.  The fudge factor won't work, because we still don't
>really know how many different modules will want to use shared memory.
>
>The solution is probably to really look at MM and determine if we really
>want to use it.  I am beginning to believe that we don't.  More later if I
>can find the time to really look into this in detail.

The problem with MM, or the way we're using it, is that it's really doing
two jobs.

1) Providing a portable method (between unix versions anyway) of getting a
block of shared memory.
2) implementing a heap within that shared block.

For things like the scoreboard we only need a single block that can be
provide by (1) alone but we can't get at it.

I think (2) is overkill for APR & makes porting to non-unix platforms more
difficult (there's still no Win32 version AFAIK). If we actually need a
heap implementation it should be at a higher, platform neutral level.

-- 
 ______________________________________________________________________________
 |  Brian Havard                 |  "He is not the messiah!                   |
 |  brianh@kheldar.apana.org.au  |  He's a very naughty boy!" - Life of Brian |
 ------------------------------------------------------------------------------


Mime
View raw message