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 16:41:18 GMT
On Tue, May 08, 2001 at 06:28:05PM +0200, jean-frederic clere wrote:
> Luke Kenneth Casson Leighton wrote:
> > 
> > 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);
> 
> Or something like:
> apr_pool_create_shared(&shmem_pool, NULL, "myglobalkey");

... where the implementation of apr_pool_create_shared is [must be,
or similar]:

shmem_sys = apr_memsys_shmem_create(global_key_name)
shmem_pool = apr_pool_from_sms_init(&shmem_sms);

> some_memory = apr_palloc(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.
> 
> I think you have to pass the key "myglobalkey" and the size. If you want to get
> the same memory area, a offset from the start of the memory is needed.

i am assuming that when you create the shmem_sys instance, it
stores the global_key_name as state info associated with
that shmem_sys apr_memsys instance, such that the ap_pool_xxx()
functions that use the pool created _from_ that shmem_sys
know, and need to know, absolutely nothing about the shmem_sys
_or_  which global_key_name, etc. etc.

all best,

luke [in a rush: have a lift home :)]

Mime
View raw message