httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Darroch <chr...@pearsoncmg.com>
Subject Re: slotmem API notes
Date Fri, 15 May 2009 19:33:39 GMT
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


Mime
View raw message