[...] >> 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.
I would have to agree. The whole point of memory systems is that once you have passed the apr_xxx_memory_system_create() phase, the code looks the same for all memory systems. Hence, you could plug in another to dump the content of the memory in a file when a block is freed, or something like that, _without_ modifying the code using the memory system. It would just be changing something like this: ... apr_memory_system *mem_sys; apr_standard_memory_system_create(&mem_sys); ... to: ... apr_memory_system *mem_sys, *original_mem_sys; apr_standard_memory_system_create(&original_mem_sys); apr_dumponfree_memory_system_create(&mem_sys, original_mem_sys, "somewhere/myfile"); ... Now that's nice isn't it? Sander
