Re: slotmen API thoughts

[Jim Jagielski <ji...@jaguNET.com>]

On Dec 31, 2008, at 3:12 PM, Chris Darroch wrote:

> Hi --
>
>  First of all, many thanks to Jim Jagielski, Jean-Frederic Clere,
> and Brian Akins for the slotmem API!  Personally I think it would be
> great to see the mod_auth_digest and/or mod_proxy module gradually  
> migrate
> toward using either the slotmem or socache APIs, as appropriate (and
> perhaps even the scoreboard itself?)
>

:)

The prime candidate for me right now is Paul's heartbeat stuff.
Reading and writing a file? How gauche! :)

>
>  A few initial thoughts, in two categories, specific and general.
>
>  In the specific realm, I think mod_sharedmem.c should not be
> hard-coded to persist data into *.slotmem files in a "logs/"  
> directory.
> I know that we install some httpd instances with non-default layouts,
> e.g., the "GNU layout" where log files live under var/apache/log and
> other runtime files under var/apache/run.
>

Yeah, I agree... I spent most of the time trying to cleanup
the actual mechanics and not worrying about the persist stuff,
which I see as secondary. Being able to make it runtime
configurable (wrt both enabling/disabling as well as location)
is on the TODO

>
>  I came the conclusion that the API more or less prevented such
> options, because access to slots is performed through pointers to
> physical memory.  The mem method returns such a pointer given an
> index.  In fact, beyond the two existing providers -- unshared and
> shared memory -- I'm not at all sure what other kinds of things
> one could really do.
>

I see slotmem and socache as complimentary.... slotmem takes care
of the actual mechanics of where the data exists and "how" it
exists and so_cache takes care of the cache-like nature of
the data (lifetime, expires, etc...)... So so_cache's SHMCBIndex
would use slotmem, for example... After all, we just pass
around void* pointers, so what they really point to is abstract.