httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Darroch <>
Subject Re: [mod_fcgid] how about spin lock on share memory
Date Wed, 14 Oct 2009 18:22:19 GMT
Jeff Trawick wrote:

> maybe increasing the granularity of the lock could help
> (multiple busy lists with the inode used as a hash to get to the
> proper busy list)

   I happen to have a module, unrelated to mod_fcgid, which manages
a fairly large shared-memory cache across a number of user sessions.
Over the years I ended up with an implementation that divides it
into 32 subcaches and gives each one a global lock; sessions are
spread across the subcaches randomly.  It may not be elegant but it
works well under a pretty high load.

   Because this runs on Linux and we're just using the APR defaults,
the process locks are SysV semaphores.  Maybe sometime in the far
future, once glibc 2.10 appears on our systems, we might try
APR_LOCK_PROC_PTHREAD and see if we can't get the shiny new
pthread_mutexattr_setrobust() support into APR.  (As a side note,
anyone know if this has come up yet in the APR world, maybe for
a recent Fedora or something?  I'm not sure what distros might have
glibc 2.10 in them at all.)

   Anyhoo, the other thing I've pondered over the years but never
tried would be to hack APR's SysV semaphore lock code to permit
multiple semaphores in a set -- right now it's just a semget(..., 1, ...)
but it would clean up our ipcs output a lot if we could pack those
32 semaphores into one set instead of having just one each in its own
set, and especially so if we ever needed more than 32.

   Well, none of that is related to what I'm supposed to be doing
this week (i.e., breaking out my old fcgid patches), nor httpd, really,
but it's maybe mildly interesting to someone, or not, as the case
may be.  :-/  OK, back to work.


GPG Key ID: 366A375B
GPG Key Fingerprint: 485E 5041 17E1 E2BB C263  E4DE C8E3 FA36 366A 375B

View raw message