Joe Orton wrote:
w.r.t. locking, my take for socache was: you either duplicate the code
in every provider, or you duplicate the code in every API consumer, so
it wasn't obvious what was best. I expected the latter would be both
simpler and more flexible, so went for that.
It looks like Jim has been busy pulling out the mutex in slotmem_shm,
so at a minimum we're in parallel at the moment, and the providers'
code is as simple as possible (at the expense of more work for their
callers).
I've wondered before whether some central API
could simplify this, such that with little extra module code, you could
get a mutex which could be configured via e.g.:
Mutex slotmem fcntl:/var/run/slotmem.lck
and if not configured, sensible defaults are used. But I'm not sure
whether it could be done to really improve the server and avoid being an
abstraction-fest code-bloat effort.
Jim Jagielski wrote:
No, I agree it's a compelling argument... How about this as a
compromise: The create/init accepts 2 additional arguments,
a locking function pointer and an unlock function pointer.
So the end user needs to determine what sort of locking they
want when using the slotmem. The slotmem then mutexes all
access to the slots with this mutex. Additionally, each
slotmem function also accepts a flag that says "use provided
locking or force no-locking", so that even if a mutex is provided,
the end-user can decide "No, I know this is safe and so I want
to do this without any locking" for an optimization.
I think both ideas could be combined in an interesting and
relatively bloat-free way. You'd want a way to be able to
use a single provider (e.g., mod_slotmem_shm) with different
locking (or none) for each instance of the provider -- a
thread-local usage might use none, while a server-wide one would
need a global mutex.
I hesitate to start proposing APIs that I know I'm not going
to have time to develop, though. (But it's so hard to resist. :-)
Personally I'm going to probably put this on the back burner and
try to spend any available spare cycles on keeping mod_slotmem_zk
in sync with trunk and finally getting into the mod_fcgid build
stuff (borrowing the framework from mod_ftpd, per wrowe's
suggestion). I'm certainly keen to hear opinions on the issue
of locking on httpd (and trying to be lock-free where
feasible) though.
Chris.
--
GPG Key ID: 366A375B
GPG Key Fingerprint: 485E 5041 17E1 E2BB C263 E4DE C8E3 FA36 366A 375B
