Changes between Version 9 and Version 10 of ModParrotArchitecture

Timestamp:

11/29/08 16:17:28 (13 years ago)

Author:

jhorwitz

Comment:

--

ModParrotArchitecture

@@ -15 +15 @@
  * PMC: Parrot Magic Cookie
  * Context: a data structure containing information about the current connection
+ * Interpreter: a Parrot interpreter ({{{Parrot_Interp}}})
 
 == Design Goals ==
@@ -57 +58 @@
 The block of Apache data structures lists all possible structures that Apache may pass to a handler.  As a rule, if any of the Apache data structures are in scope, mod_parrot MUST update the corresponding pointer in the context before calling a metahandler.  This ensures that metahandlers can access the proper data structures, as they are given only the context to work with.
 
-To maintain state, the same context must be used for all phases of a request, as it contains a reference to the interpreter.
-
 === Context Pools ===
 
-Contexts are allocated from context pools, which are populated at startup and tuned dynamically at runtime.  Contexts contain pointers to Parrot interpreters so this also provides mod_parrot with a pool of interpreters.
+Contexts are allocated from context pools, which are populated at startup and tuned dynamically at runtime.  There is a single global pool, plus one pool per virtual host configured with {{{+Parent}}}. Virtual hosts without {{{+Parent}}} share the global pool.  Contexts contain pointers to Parrot interpreters so this also provides mod_parrot with a pool of interpreters.  Contexts are aware of their slot in the pool array (see {{{pool_index}}}).
 
-==== Interpreter Lifecycle ====
+=== Context Lifecycle ===
+
+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.
+
+
+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 {{{conn_rec *c}}} is non-null, {{{init_ctx}}} will return the context bound to that connection, or bind an available connection and return it.  Code in hooks that run before the pre-connection phase should pass a NULL connection.
+
+When a context is in use, it is locked behind the scenes by {{{reserve_ctx}}}.  While code should not call this function directly, it MUST call {{{release_ctx}}} after each phase is complete to unlock the context.  This may change in the future, as connection binding requires the use of the same context, so all this locking and unlocking is just overhead.
+
+When the request/connection is complete, it is unlocked and disassociated from the connection by {{{modparrot_conn_cleanup}}}, a connection-scope pool cleanup handler. 
 
 == Apache Interface ==