apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From jean-frederic clere <jfrederic.cl...@fujitsu-siemens.com>
Subject Re: apr_memory_system.c;apr_memory_system.h
Date Tue, 08 May 2001 16:28:05 GMT
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");
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.

> ... 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].

Ok, it means same key.

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

Like mm_lock() mm_unlock().

> 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

View raw message