Changes between Version 19 and Version 20 of ModParrotArchitecture

Timestamp:

11/30/08 19:16:58 (13 years ago)

Author:

jhorwitz

Comment:

--

ModParrotArchitecture

@@ -31 +31 @@
 === Configuration ===
 
+mod_parrot itself requires very little configuration, and most of it should be done from the HLL layer.  Most tunables have corresponding Apache directives that you can use in httpd.conf.
+
+'''Paths'''
+
+'''Options'''
+
+||'''C Option'''||'''ParrotOptions equivalent'''||'''Default'''||'''Description'''||
+||MP_OPT_ENABLE||Enable||On||Enables mod_parrot and HLL modules for the main server or virtual host||
+||MP_OPT_PARENT||Parent||Off||Dedicates a separate context pool for a virtual host||
+||MP_OPT_TRACEINIT||TraceInit ||Off||Trace mod_parrot initialization code (can be verbose)||
+
+
 === Contexts ===
 
@@ -61 +73 @@
 Contexts are created at Apache startup during the configuration phase, when interpreters are needed to register various HLL modules and parse directives.  An interpreter is always started when a context is created.
 
-XXX Forking?
+Child processes in forking MPMs inherit (via {{{fork()}}}) the context pools created at startup, saving both CPU cycles and memory.
 
 To maintain state, the same context must be used for all phases of a request, as it contains a reference to the interpreter.  When a context is needed, code should call {{{init_ctx(server_rec *s, conn_rec *c)}}}, which will return an available context from the pool.  If {{{c}}} is non-null, {{{init_ctx}}} will either return the context bound to that connection, or bind and return an available context if none is already bound.  Code in hooks that run before the pre-connection phase should pass a NULL connection.