Add docs on process-group and application group options for WSGIScrip…

…tAlias[Match].

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

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.