Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Received-SPF: pass (nike.apache.org: domain of jim@jagunet.com designates
 209.133.199.10 as permitted sender)
Message-Id: <F88BCF62-B872-4013-AE57-6CB8401226C1@jaguNET.com>
From: Jim Jagielski <jim@jaguNET.com>
To: dev@httpd.apache.org
In-Reply-To: <495BD219.9090308@pearsoncmg.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v930.3)
Subject: Re: slotmen API thoughts
Date: Thu, 1 Jan 2009 11:44:20 -0500
References: <495BD219.9090308@pearsoncmg.com>


On Dec 31, 2008, at 3:12 PM, Chris Darroch wrote:
>
> - model API closely on socache API
>
> - include/ap_slotcache.h defines the following:
>
> - does not define internals of ap_slotcache_t; leave that to providers
>
> - no lock/unlock functions; leave that to callers but signal
>   need for them with AP_SLOTCACHE_FLAG_NOTMPSAFE (parallel to
>   AP_SOCACHE_FLAG_NOTMPSAFE, note "NOTMPSAFE" == "not MP-safe")
>
> - slotcache provider methods:
>
>   - create()   - takes num_items and item_size
>                - to be called during initial config pass, providers
>                  should not initialize or create mutexes here, etc.

"should not"??

>
>   - init()     - to be called during post-config pass, passed pconf  
> pool,
>                  performs real initialization
>   - destroy()  - to be called from pconf pool cleanup
>   - store()    - takes index, value of item_size length
>   - retrieve() - takes index and unsigned char* buffer to write into
>   - reset()    - takes index, clears value
>   - maybe do(), or status(), akin to socache's status()?
>
> - AP_SLOTCACHE_PROVIDER_GROUP ("slotcache") and
>   AP_SLOTCACHE_PROVIDER_VERSION ("0")
>
>  To my mind, the great advantage of having accessor methods like
> store(), retrieve(), and reset() instead of a mem() method is that
> a wide variety of providers can be envisioned.
>

I agree that abstracting out get/set (or retrieve/store) allows
for more generic usages... also allows for the provider itself
to determine if mutexes are needed or not... Maybe I'll have
some time over the weekend to hash this out.

One thing which adds a wrinkle is that I envision various modules
using various providers for slotmem, so, for example, mod_proxy
would used shared mem and mod_cache would use DBM for example.
In this case, you have one interface to 2 providers working at
the same time and I'm not sure if ap_slotcache_t collisions
could occur (if DBM defines it one way and sharedmem defines
it another, and both providers are compiled and active, will
stuff break?)... That was the rationale behind up-front defining
the struct but trying to make it generic enough...