Merge branch 'release/4.5.24'

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.

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

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.

src/server/mod_wsgi.c

@@ -10709,7 +10709,7 @@ static apr_status_t wsgi_socket_sendv(apr_socket_t *sock, struct iovec *vec,
     if (nvec > iov_max) {
         int offset = 0;
 
-        while (nvec > 0) {
+        while (nvec != 0) {
             apr_status_t rv;
 
             rv = wsgi_socket_sendv_limit(sock, &vec[offset],
@@ -10718,8 +10718,12 @@ static apr_status_t wsgi_socket_sendv(apr_socket_t *sock, struct iovec *vec,
             if (rv != APR_SUCCESS)
                 return rv;
 
-            nvec -= iov_max;
-            offset += iov_max;
+            if (nvec > iov_max) {
+                nvec -= iov_max;
+                offset += iov_max;
+            } else {
+                nvec = 0;
+            }
         }
 
         return APR_SUCCESS;

src/server/wsgi_version.h

@@ -25,8 +25,8 @@
 
 #define MOD_WSGI_MAJORVERSION_NUMBER 4
 #define MOD_WSGI_MINORVERSION_NUMBER 5
-#define MOD_WSGI_MICROVERSION_NUMBER 23
-#define MOD_WSGI_VERSION_STRING "4.5.23"
+#define MOD_WSGI_MICROVERSION_NUMBER 24
+#define MOD_WSGI_VERSION_STRING "4.5.24"
 
 /* ------------------------------------------------------------------------- */