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.
