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