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
