apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sander Striker" <stri...@samba-tng.org>
Subject RE: apr_memory_system.c;apr_memory_system.h
Date Tue, 08 May 2001 18:13:17 GMT
[...]
>> 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


Mime
View raw message