| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@645455 13f79535-47bb-0310-9956-ffa450edef68
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
cannot be data symbols when mod_ssl is built as a loadable module;
using an external string constant in a loadable module is not portable.
Also reorganize file and sem to follow their explicit mechanisms,
and ensured that the explicit mechansims are listed in order of
preference.
This raises a question, would [fcntl|file] be a clearer way of
indiciating what the file/sem methods devolve to?
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@568833 13f79535-47bb-0310-9956-ffa450edef68
|
| |
|
|
| |
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@568794 13f79535-47bb-0310-9956-ffa450edef68
|
|
|
locking method and the lockfile location, I never
liked how AcceptMutex was linked to LockFile. This
seemed unnecessary. Much better to have AcceptMutex
do both as well. Plus, now that we will likely see
other modules require a "standard" way of setting
mutexes, why not have Apache provide that as
an API of sorts.
Anyway, LockFile is now depreciated and AcceptMutex
is now SSLMutex-like. We also provide a short
function that "parses" out a mutex parameter
and strips out the mechanism and lockfile location.
AcceptMutex and SSLMutex is this capability.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@467326 13f79535-47bb-0310-9956-ffa450edef68
|
