On 09/03/2009 04:30 PM, Jim Jagielski wrote:
On May 15, 2009, at 3:33 PM, Chris Darroch wrote:
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.
After thinking and using slotmem, I'm no longer convinced that pulling
out the lock/unlock was such a good idea... or at least completely.
Consider this use case: Apache starts off and uses the shared memory
slotmem. It uses it's own locking and all access to the data from Apache
or any child process can inherit that lock and all is good.
But consider an independent process that wants to attach to that
shared memory segment... at this point, we need a global lock that
both Apache and this ind process will honor. So somehow we need to
store that lock *in* the shared memory segment, so that all processes
that attach to it can use it.
Ideas or comments?
I like the idea, I made prototypes but at the end it was more easy to
write an httpd handler to expose the contents of the slotmem. May be we
can have a module that provides locks and use to 2 providers (one for
the slotmem and one for the lock)?
Cheers
Jean-Frederic
