httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Jagielski <>
Subject Re: slotmem API notes
Date Thu, 03 Sep 2009 14:30:45 GMT

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?

View raw message