trawick at gmail
Nov 23, 2009, 3:59 PM
Post #2 of 10
(923 views)
Permalink
|
|
Re: svn commit: r883540 - in /httpd/httpd/trunk: ./ build/ docs/conf/ docs/conf/extra/ include/ modules/aaa/ modules/core/ modules/examples/ modules/generators/ modules/ldap/ modules/mappers/ modules/ssl/ server/ server/mpm/prefork/ server/mpm/worker
[In reply to]
|
|
On Mon, Nov 23, 2009 at 6:33 PM, William A. Rowe Jr.
<wrowe [at] rowe-clan> wrote:
> trawick [at] apache wrote:
>> Author: trawick
>> Date: Mon Nov 23 23:17:51 2009
>> New Revision: 883540
>>
>> URL: http://svn.apache.org/viewvc?rev=883540&view=rev
>> Log:
>> Replace AcceptMutex, LockFile, RewriteLock, SSLMutex, SSLStaplingMutex,
>> and WatchdogMutexPath with a single Mutex directive. Add APIs to
>> simplify setup and user customization of APR proc and global mutexes.
>> (See util_mutex.h.) Build-time setting DEFAULT_LOCKFILE is no longer
>> respected; set DEFAULT_REL_RUNTIMEDIR instead.
>
> I haven't spent enough time follow the discussion thread, but there is a
> pretty big concern here.
>
> Let's say we pick NFS for our SSL session store, which means we need an fcntl
> or file lock to mutex the session cache. But if these others were all machine
> local (and hopefully, easily threadproc mutexible, such as a pthread mutex or
> at worst case, a sysv sem) then the optimal no longer mirrors the appropriate
> match based on the resource.
>
> Can we perhaps partially revert to allow these to be -overrides- of the system
> wide mutex mechanism, e.g. sysv sem might be right for all but two resources.
> Let those two be overridden (and point out, in the docs, when this would become
> necessary).
>
I may not understand you, but here goes:
These are overrides of the compiled-in defaults (APR's default mutex
mech, httpd's default mutex file directory).
When you add
Mutex ssl-cache flock:/any/directory
that setting would override the compiled-in defaults just for that
mutex, and others would still be (e.g., on Linux) SysV semaphores.
If you then add
Mutex default posixsem
the ssl-cache mutex is still flock on the specified directory, but
everything else is a Posix semaphore.
What is missing for your scenario AFAICT is having a predictable lock
file name so that different nodes can share the same mutex file.
Currently on Unix the pid will always be appended to the lock file
name.
We could have an option on the ap_{global,proc}_mutex_create() or
ap_mutex_register() call to omit the pid from the lock file name.
Alternatively we could have an option on ap_mutex_register() to
indicate that the path specified on the Mutex directory, or in the
path parameter to ap_mutex_register(), is the absolute name of the
lock file.
Having this no-pid option hard-coded inside the module is a bit
hurtful, as getting the pid-qualified name by default avoids the
requirement for additional configuration when multiple httpd instances
on the same node share a lock directory.
Requiring that the full basename be coded on the Mutex directive is
hurtful since generally you just want to say "move it here", and in
fact most often you'd say "move them all here" by coding "Mutex
default file:/some/dir".
I guess something could be coded on the Mutex directive to indicate
that the given pathname is the entire lock file path for the given
mutex.
Make sense?
|
win-api-fix.txt
