apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Luke Kenneth Casson Leighton <l...@samba-tng.org>
Subject Re: apr_memory_system.c;apr_memory_system.h
Date Tue, 08 May 2001 15:07:48 GMT
On Tue, May 08, 2001 at 12:32:04PM +0200, jean-frederic clere wrote:

> Hi,
> 
> I am little confused... But these nice things have nothing to do with shared
> memory, don't they?
> So the locking issue is for threads.

not quite just for threads.

take this:

shmem_pool = apr_pool_from_sms_init(&shmem_sms);
some_memory = ap_pool_alloc(shmem_pool, some_size);

... then, you pass the address and size of that memory
over to some other process [not a thread] and start
accessing it.

... or, better, you get the two processes to set up
their variable, shmem_pool, as the same, and to return
some_memory to access the same shared memory [not entirely
happy with concept of overloading the ap_pool semantics
to do this, ah well].

between the two processes, you will need locking on
the shared memory. (handled by the shmem_sms instance).

that's nothing to do with threads.

the allocation / management of blocks of shared memory
requires shared memory to globally store a linked list
etc. of the shared memory blocks, such that other
shared-mem-memsys instances can access / manage it /
provide access to the same shared memory blocks / pools.

nothing to do with threads, although the techniques
required to manage ordinary memory between threads are
similar to those required to manage shared memory
between processes.

the complications are caused by the fact that any
pointers stored in the shmem block have to be relative to
the start of the shmem block, not to the memory they
are mapped into.  [but this is standard procedure: i'm
telling you nothing new, here].

luke


Mime
View raw message