Shared memory

[David Reid <dr...@jetnet.co.uk>]

We've had a fair bit of discussion, but I don't think we ever got to a
decision did we?  From what I remember...

1. we like the basic malloc/calloc/realloc/free interfaces for using the
memory
2. if we ask for 1000 bytes we want 1000 bytes with any allocation for
headers being "outside" our block  This is a problem in that we never really
know how many allocations we'll make from a block and therefore how much
extra memory the structures we use to track the blocks will need.

One possible way to be to follow the example of the tracking system and have
a parent memory_system be required when creating the shared memory system,
and allocate all the structures from that.  This would preserve the shared
memory, but probably isn't an optimal solution.

So, shall we go around again ??? :)

david

Re: Shared memory

[Luke Kenneth Casson Leighton <lk...@samba-tng.org>]

On Wed, May 30, 2001 at 12:52:14PM +0100, David Reid wrote:

> We've had a fair bit of discussion, but I don't think we ever got to a
> decision did we?  From what I remember...
> 
> 1. we like the basic malloc/calloc/realloc/free interfaces for using the
> memory
> 2. if we ask for 1000 bytes we want 1000 bytes with any allocation for
> headers being "outside" our block  This is a problem in that we never really
> know how many allocations we'll make from a block and therefore how much
> extra memory the structures we use to track the blocks will need.
> 
> One possible way to be to follow the example of the tracking system and have
> a parent memory_system be required when creating the shared memory system,
> and allocate all the structures from that.  This would preserve the shared
> memory, but probably isn't an optimal solution.
> 
> So, shall we go around again ??? :)

:)

iirc, i proposed that an extra function be added [to apr_pool,
to apr_sms, doesn't matter which] that allows you
to be able to 'dig' into the shared memory, in order to find
the chunk of shared memory that you require.

so.... basically... it must be possible to initialise a sh-memory
area, and then tell sms / pool, in another process / program to
'mirror' that area _as if_ you had initialised and malloced etc.
from it _in that process / program_.

this is expensive, esp. as every time you wish to malloc / realloc / free,
you will need to lock, 'mirror', modify, unlock.


alternative approach:

if you keep all of the tracking/headers _in_ shared memory,
lock them etc., you avoid the problem of having to re-initialise
a 'mirror' sms / pool.  you guarantee consistency, etc.

it _does_ mean, however, that we will need to design an
'accounting' sms that is shared-memory aware [i.e. can
cope with its linked-lists being shmem-relative, not
actual-pointers-in-memory].

funnily enough, the sms API already caters for that eventuality,
by being able to use a different sms for accounting from
user-allocated memory.

luke