4 files changed, 99 insertions, 2 deletions
diff --git a/docs/configuration-directives/WSGIScriptAlias.rst b/docs/configuration-directives/WSGIScriptAlias.rst
index e0d17d7..708dabe 100644
--- a/docs/configuration-directives/WSGIScriptAlias.rst
+++ b/docs/configuration-directives/WSGIScriptAlias.rst
@@ -3,7 +3,7 @@ WSGIScriptAlias
 ===============
 
 :Description: Maps a URL to a filesystem location and designates the target as a WSGI script.
-:Syntax: ``WSGIScriptAlias`` *URL-path file-path|directory-path*
+:Syntax: ``WSGIScriptAlias`` *URL-path file-path|directory-path* ``[`` *options* ``]``
 :Context: server config, virtual host
 
 The WSGIScriptAlias directive behaves in the same manner as the
@@ -59,6 +59,44 @@ location, potentially bypassing the WSGIScriptAlias and revealing the
 source code of the WSGI scripts if they are not restricted by a
 `<Directory>`_ section.
 
+Options which can be supplied to the ``WSGIScriptAlias`` directive are:
+
+**process-group=name**
+    Defines which process group the WSGI application will be executed
+    in. All WSGI applications within the same process group will execute
+    within the context of the same group of daemon processes.
+
+    If the name is set to be ``%{GLOBAL}`` the process group name will
+    be set to the empty string. Any WSGI applications in the global
+    process group will always be executed within the context of the
+    standard Apache child processes. Such WSGI applications will incur
+    the least runtime overhead, however, they will share the same
+    process space with other Apache modules such as PHP, as well as the
+    process being used to serve up static file content. Running WSGI
+    applications within the standard Apache child processes will also
+    mean the application will run as the user that Apache would normally
+    run as.
+
+**application-group=name**
+    Defines which application group a WSGI application or set of WSGI
+    applications belongs to. All WSGI applications within the same
+    application group will execute within the context of the same Python
+    sub interpreter of the process handling the request.
+
+    If the name is set to be ``%{GLOBAL}`` the application group will be
+    set to the empty string. Any WSGI applications in the global
+    application group will always be executed within the context of the
+    first interpreter created by Python when it is initialised. Forcing
+    a WSGI application to run within the first interpreter can be
+    necessary when a third party C extension module for Python has used
+    the simplified threading API for manipulation of the Python GIL and
+    thus will not run correctly within any additional sub interpreters
+    created by Python.
+
+If both ``process-group`` and ``application-group`` options are set, the
+WSGI script file will be pre-loaded when the process it is to run in is
+started, rather than being lazily loaded on the first request.
+
 .. _Alias: http://httpd.apache.org/docs/2.2/mod/mod_alias.html#alias
 .. _DocumentRoot: http://httpd.apache.org/docs/2.2/mod/core.html#documentroot
 .. _<Directory>: http://httpd.apache.org/docs/2.2/mod/core.html#directory
diff --git a/docs/configuration-directives/WSGIScriptAliasMatch.rst b/docs/configuration-directives/WSGIScriptAliasMatch.rst
index eb3f397..576797b 100644
--- a/docs/configuration-directives/WSGIScriptAliasMatch.rst
+++ b/docs/configuration-directives/WSGIScriptAliasMatch.rst
@@ -3,7 +3,7 @@ WSGIScriptAliasMatch
 ====================
 
 :Description: Maps a URL to a filesystem location and designates the target as a WSGI script.
-:Syntax: ``WSGIScriptAliasMatch`` *regex file-path|directory-path*
+:Syntax: ``WSGIScriptAliasMatch`` *regex file-path|directory-path* ``[`` *options* ``]``
 :Context: server config, virtual host
 
 This directive is similar to the WSGIScriptAlias directive, but makes use
@@ -31,3 +31,41 @@ critical.
 If you think you need to use WSGIScriptAliasMatch, you probably don't
 really. If you really really think you need it, then check on the mod_wsgi
 mailing list about how to use it properly.
+
+Options which can be supplied to the ``WSGIScriptAlias`` directive are:
+
+**process-group=name**
+    Defines which process group the WSGI application will be executed
+    in. All WSGI applications within the same process group will execute
+    within the context of the same group of daemon processes.
+
+    If the name is set to be ``%{GLOBAL}`` the process group name will
+    be set to the empty string. Any WSGI applications in the global
+    process group will always be executed within the context of the
+    standard Apache child processes. Such WSGI applications will incur
+    the least runtime overhead, however, they will share the same
+    process space with other Apache modules such as PHP, as well as the
+    process being used to serve up static file content. Running WSGI
+    applications within the standard Apache child processes will also
+    mean the application will run as the user that Apache would normally
+    run as.
+
+**application-group=name**
+    Defines which application group a WSGI application or set of WSGI
+    applications belongs to. All WSGI applications within the same
+    application group will execute within the context of the same Python
+    sub interpreter of the process handling the request.
+
+    If the name is set to be ``%{GLOBAL}`` the application group will be
+    set to the empty string. Any WSGI applications in the global
+    application group will always be executed within the context of the
+    first interpreter created by Python when it is initialised. Forcing
+    a WSGI application to run within the first interpreter can be
+    necessary when a third party C extension module for Python has used
+    the simplified threading API for manipulation of the Python GIL and
+    thus will not run correctly within any additional sub interpreters
+    created by Python.
+
+If both ``process-group`` and ``application-group`` options are set, the
+WSGI script file will be pre-loaded when the process it is to run in is
+started, rather than being lazily loaded on the first request.
diff --git a/docs/release-notes.rst b/docs/release-notes.rst
index 9398976..600e295 100644
--- a/docs/release-notes.rst
+++ b/docs/release-notes.rst
@@ -5,6 +5,7 @@ Release Notes
 .. toctree::
    :maxdepth: 2
 
+   release-notes/version-4.5.24
    release-notes/version-4.5.23
    release-notes/version-4.5.22
    release-notes/version-4.5.21
diff --git a/docs/release-notes/version-4.5.24.rst b/docs/release-notes/version-4.5.24.rst
new file mode 100644
index 0000000..fb9067c
--- /dev/null
+++ b/docs/release-notes/version-4.5.24.rst
@@ -0,0 +1,20 @@
+==============
+Version 4.5.24
+==============
+
+Version 4.5.24 of mod_wsgi can be obtained from:
+
+  https://codeload.github.com/GrahamDumpleton/mod_wsgi/tar.gz/4.5.24
+
+Bugs Fixed
+----------
+
+* Using mod_wsgi in daemon mode on Solaris would cause a process hang or
+  max out CPU usage. Caused by change of variable type to unsigned to get
+  rid of compiler warnings, without fixing how condition check using
+  variable was done.
+
+  Problem could also affect non Solaris systems if total number of HTTP
+  headers and other variables passed in WSGI environ was greater than 1024.
+  Affected Solaris all the time due to it having a limit of only 16 in
+  operating system for same code, meaning hit problem immediately.