This is an automated email from the ASF dual-hosted git repository.

mxmanghi pushed a commit to branch quattuor
in repository https://gitbox.apache.org/repos/asf/tcl-rivet.git

commit 9f804b0e3ce0738785a7c11bbc649679c80756ca
Author: Massimo Manghi <mxman...@apache.org>
AuthorDate: Mon Oct 14 10:46:39 2019 +0200

    update internals doc to 4.0 code design
---
 doc/xml/internals.xml | 23 +++++++++++++++++------
 1 file changed, 17 insertions(+), 6 deletions(-)

diff --git a/doc/xml/internals.xml b/doc/xml/internals.xml
index 5bec822..d5cd7a3 100644
--- a/doc/xml/internals.xml
+++ b/doc/xml/internals.xml
@@ -1,6 +1,4 @@
-<!-- $Id: $ -->
-
-  <section id="internals">
+<section id="internals">
     <title>Rivet Internals</title>
     <para>
       This section easily falls out of date, as new code is added, old
@@ -144,17 +142,30 @@
                                        to have details on how and at what 
stage this callback is invoked.
                                </listitem>
                                <listitem>
+                                       <para>
                                        <emphasis>thread_interp</emphasis> must 
be a function returning
                                        the interpreter object (a pointer to 
record of type
                                        <command>rivet_thread_interp</command>) 
associated
                                        to a given configuration as stored in a 
<command>rivet_server_conf*</command>
                                        object. This element was temporarily 
introduced in the 
                                        <command>mpm_bridge_table</command> 
table and should be accessed
-                                       through the macro RIVET_PEEK_INTERP.
+                                       through the macro 
RIVET_PEEK_INTERP.</para>
                                        <programlisting>interp_obj = 
RIVET_PEEK_INTERP(private,private->conf);</programlisting>
-                                       Every bridge implementation should have 
its own way to store interpreter data and manage their
+                                       <para>Every bridge implementation 
should have its own way to store interpreter data and manage their
                                        status. So this macro (and associated 
function) should hide from the module core function
-                                       the specific approach followed in a 
particular bridge
+                                       the specific approach followed in a 
particular bridge</para>
+                                       <para>The current implementation of 
this function is used both
+                                       to store and retrieve a 
<command>rivet_thread_interp</command> pointer in
+                                       the bridge internal data structures. 
For instance this is the function
+                                       of the prefork bridge</para>
+                                       <programlisting>rivet_thread_interp* 
PreforkBridge_Interp (rivet_thread_private* private,
+                                            rivet_server_conf*    conf,
+                                            rivet_thread_interp*  interp)
+{
+    if (interp != NULL) { private->ext->interps[conf->idx] = interp; }
+
+    return private->ext->interps[conf->idx];   
+}</programlisting>
                                </listitem>
                        </itemizedlist>
                </para>


---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@tcl.apache.org
For additional commands, e-mail: commits-h...@tcl.apache.org

Reply via email to