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 :)]
