Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP
Browse files

Split out configuration directives to individual files.

  • Loading branch information...
commit b184ffe1c5c6fa0c6cf67af10b0e5852d48cfeb6 1 parent 3509a95
@GrahamDumpleton authored
View
102 ConfigurationDirectives.rst
@@ -1,5 +1,3 @@
-
-
========================
Configuration Directives
========================
@@ -1390,103 +1388,3 @@ execute from secondary threads. Similarly, when using daemon mode, request
handlers would executed from secondary threads. Only code run as a side
effect of WSGIImportScript is guaranteed to be executed in main Python
interpreter thread.
-
-WSGIAcceptMutex
----------------
-
-|| *[http://httpd.apache.org/docs/2.2/mod/directive-dict.html#Description Description:]* || Specify type of accept mutex used by daemon processes. ||
-|| *[http://httpd.apache.org/docs/2.2/mod/directive-dict.html#Syntax Syntax:]* || `WSGIAcceptMutex Default|method` ||
-|| *[http://httpd.apache.org/docs/2.2/mod/directive-dict.html#Default Default:]* || `WSGIAcceptMutex Default` ||
-|| *[http://httpd.apache.org/docs/2.2/mod/directive-dict.html#Context Context:]* || server config ||
-|| *[http://httpd.apache.org/docs/2.2/mod/directive-dict.html#Module Module:]* || mod_wsgi.c ||
-
-The WSGIAcceptMutex directive sets the method that mod_wsgi will use to
-serialize multiple daemon processes in a process group accepting requests
-on a socket connection from the Apache child processes. If this directive
-is not defined then the same type of mutex mechanism as used by Apache for
-the main Apache child processes when accepting connections from a client
-will be used. If set the method types are the same as for the Apache
-[http://httpd.apache.org/docs/2.2/mod/mpm_common.html#acceptmutex AcceptMutex]
-directive.
-
-Note that the WSGIAcceptMutex directive and corresponding features are
-not available on Windows or when running Apache 1.3.
-
-WSGILazyInitialization
-----------------------
-
-|| *[http://httpd.apache.org/docs/2.2/mod/directive-dict.html#Description Description:]* || Enable/disable lazy initialisation of Python. ||
-|| *[http://httpd.apache.org/docs/2.2/mod/directive-dict.html#Syntax Syntax:]* 3.0+ || `WSGILazyInitialization On|Off` ||
-|| *[http://httpd.apache.org/docs/2.2/mod/directive-dict.html#Default Default:]* 3.0+ || `WSGILazyInitialization On` ||
-|| *[http://httpd.apache.org/docs/2.2/mod/directive-dict.html#Context Context:]* || server config ||
-|| *[http://httpd.apache.org/docs/2.2/mod/directive-dict.html#Module Module:]* || mod_wsgi.c ||
-
-*Note: This directive was only added in mod_wsgi version 2.0.*
-
-The WSGILazyInitialization directives sets whether or not the Python
-interpreter is preinitialised within the Apache parent process or whether
-lazy initialisation is performed, and the Python interpreter only
-initialised in the Apache server processes or mod_wsgi daemon processes
-after they have forked from the Apache parent process.
-
-In versions of mod_wsgi prior to version 3.0 the Python interpreter was
-always preinitialised in the Apache parent process. This did mean that
-theoretically some benefit in memory usage could be derived from delayed
-copy on write semantics of memory inherited by child processes that was
-initialised in the parent. This memory wasn't significant however and was
-tempered by the fact that the Python interpreter when destroyed and then
-reinitialised in the Apache parent process on an Apache restart, would with
-some Python versions leak memory. This meant that if a server had many
-restarts performed, the Apache parent process and thus all forked child
-processes could grow in memory usage over time, eventually necessitating
-Apache be completely stopped and then restarted.
-
-This issue of memory leaks with the Python interpreter reached an extreme
-with Python 3.0, where by design, various data structures would not be
-destroyed on the basis that it would be reused when Python interpreter was
-reinitialised within the same process. The problem is that when an Apache
-restart is performed, mod_wsgi and the Python library are unloaded from
-memory, with the result that the references to that memory would be lost
-and so a real memory leak, of significant size and much worse that older
-versions of Python, would result.
-
-As a consequence, with mod_wsgi 3.0 and onwards, the Python interpreter is
-not initialised by default in the Apache parent process for any version of
-Python. This avoids completely the risk of cummulative memory leaks by the
-Python interpreter on a restart into the Apache parent process, albeit with
-potential for a slight increase in child process memory sizes. If need be,
-the existing behaviour can be restored by setting the directive with the
-value 'Off'.
-
-A further upside of using lazy initialisation is that if you are using
-daemon mode only, ie., not using embedded mode, you can completely turn off
-initialisation of the Python interpreter within the main Apache server
-child process. Unfortunately, because it isn't possible in the general case
-to know whether embedded mode will be needed or not, you will need to
-manually set the configuration to do this. This can be done by setting:
-
-::
-
- WSGIRestrictEmbedded On
-
-
-With restrictions on embedded mode enabled, any attempt to run a WSGI
-application in embedded mode will fail, so it will be necessary to ensure
-all WSGI applications are delegated to run in daemon mode. Although WSGI
-applications will be restricted from being run in embedded mode and the
-Python interpreter therefore not initialised, it will fallback to being
-initialised if you use any of the Python hooks for access control,
-authentication or authorisation providers, or WSGI application dispatch
-overrides.
-
-Note that if mod_python is being used in the same Apache installation,
-because mod_python takes precedence over mod_wsgi in initialising the
-Python interpreter, lazy initialisation cannot be done and so Python
-interpreter will continue to be preinitialised in the Apache parent process
-regardless of the setting of WSGILazyInitialization. Use of mod_python will
-thus perpetuate the risk of memory leaks and growing memory use of Apache
-process. This is especially the case since mod_python doesn't even properly
-destroy the Python interpreter in the Apache parent process on a restart
-and so all memory associated with the Python interpreter is leaked and not
-just that caused by the Python interpreter when it is destroyed and doesn't
-clean up after itself.
View
23 configuration-directives/WSGIAcceptMutex.rst
@@ -1,3 +1,26 @@
===============
WSGIAcceptMutex
===============
+
++----------------+-----------------------------------------------------------+
+| Description | Specify type of accept mutex used by daemon processes. |
++----------------+-----------------------------------------------------------+
+| Syntax | ``WSGIAcceptMutex Default|method`` |
++----------------+-----------------------------------------------------------+
+| Default | ``WSGIAcceptMutex Default`` |
++----------------+-----------------------------------------------------------+
+| Context | server config |
++----------------+-----------------------------------------------------------+
+
+The WSGIAcceptMutex directive sets the method that mod_wsgi will use to
+serialize multiple daemon processes in a process group accepting requests
+on a socket connection from the Apache child processes. If this directive
+is not defined then the same type of mutex mechanism as used by Apache for
+the main Apache child processes when accepting connections from a client
+will be used. If set the method types are the same as for the Apache
+`AcceptMutex`_ directive.
+
+Note that the WSGIAcceptMutex directive and corresponding features are
+not available on Windows or when running Apache 1.3.
+
+.. _AcceptMutex: http://httpd.apache.org/docs/2.2/mod/mpm_common.html#acceptmutex
View
77 configuration-directives/WSGILazyInitialization.rst
@@ -1,3 +1,80 @@
======================
WSGILazyInitialization
======================
+
++----------------+-----------------------------------------------------------+
+| Description | Enable/disable lazy initialisation of Python. |
++----------------+-----------------------------------------------------------+
+| Syntax (3.0+) | ``WSGILazyInitialization On|Off`` |
++----------------+-----------------------------------------------------------+
+| Default (3.0+) | ``WSGILazyInitialization On`` |
++----------------+-----------------------------------------------------------+
+| Context | server config |
++----------------+-----------------------------------------------------------+
+
+**Note: This directive was only added in mod_wsgi version 3.0.**
+
+The WSGILazyInitialization directives sets whether or not the Python
+interpreter is preinitialised within the Apache parent process or whether
+lazy initialisation is performed, and the Python interpreter only
+initialised in the Apache server processes or mod_wsgi daemon processes
+after they have forked from the Apache parent process.
+
+In versions of mod_wsgi prior to version 3.0 the Python interpreter was
+always preinitialised in the Apache parent process. This did mean that
+theoretically some benefit in memory usage could be derived from delayed
+copy on write semantics of memory inherited by child processes that was
+initialised in the parent. This memory wasn't significant however and was
+tempered by the fact that the Python interpreter when destroyed and then
+reinitialised in the Apache parent process on an Apache restart, would with
+some Python versions leak memory. This meant that if a server had many
+restarts performed, the Apache parent process and thus all forked child
+processes could grow in memory usage over time, eventually necessitating
+Apache be completely stopped and then restarted.
+
+This issue of memory leaks with the Python interpreter reached an extreme
+with Python 3.0, where by design, various data structures would not be
+destroyed on the basis that it would be reused when Python interpreter was
+reinitialised within the same process. The problem is that when an Apache
+restart is performed, mod_wsgi and the Python library are unloaded from
+memory, with the result that the references to that memory would be lost
+and so a real memory leak, of significant size and much worse that older
+versions of Python, would result.
+
+As a consequence, with mod_wsgi 3.0 and onwards, the Python interpreter is
+not initialised by default in the Apache parent process for any version of
+Python. This avoids completely the risk of cummulative memory leaks by the
+Python interpreter on a restart into the Apache parent process, albeit with
+potential for a slight increase in child process memory sizes. If need be,
+the existing behaviour can be restored by setting the directive with the
+value 'Off'.
+
+A further upside of using lazy initialisation is that if you are using
+daemon mode only, ie., not using embedded mode, you can completely turn off
+initialisation of the Python interpreter within the main Apache server
+child process. Unfortunately, because it isn't possible in the general case
+to know whether embedded mode will be needed or not, you will need to
+manually set the configuration to do this. This can be done by setting::
+
+ WSGIRestrictEmbedded On
+
+With restrictions on embedded mode enabled, any attempt to run a WSGI
+application in embedded mode will fail, so it will be necessary to ensure
+all WSGI applications are delegated to run in daemon mode. Although WSGI
+applications will be restricted from being run in embedded mode and the
+Python interpreter therefore not initialised, it will fallback to being
+initialised if you use any of the Python hooks for access control,
+authentication or authorisation providers, or WSGI application dispatch
+overrides.
+
+Note that if mod_python is being used in the same Apache installation,
+because mod_python takes precedence over mod_wsgi in initialising the
+Python interpreter, lazy initialisation cannot be done and so Python
+interpreter will continue to be preinitialised in the Apache parent process
+regardless of the setting of WSGILazyInitialization. Use of mod_python will
+thus perpetuate the risk of memory leaks and growing memory use of Apache
+process. This is especially the case since mod_python doesn't even properly
+destroy the Python interpreter in the Apache parent process on a restart
+and so all memory associated with the Python interpreter is leaked and not
+just that caused by the Python interpreter when it is destroyed and doesn't
+clean up after itself.
Please sign in to comment.
Something went wrong with that request. Please try again.