new .internal_allocator configuration IUNTESTED)

new configuration option .internal_allocator to help LuaJIT users. THIS IS YET UNTESTED, USE AT YOUR OWN RISKS.

1 files changed, 25 insertions, 9 deletions

diff --git a/index.html b/index.html
index 0e1a30b..b1c514d 100644
--- a/index.html
+++ b/index.html
@@ -64,13 +64,13 @@
                 <font size="-1">
                         <p>
                                 <br/>
-                                <i>Copyright &copy; 2007-22 Asko Kauppi, Benoit Germain. All rights reserved.</i>
+                                <i>Copyright &copy; 2007-23 Asko Kauppi, Benoit Germain. All rights reserved.</i>
                                 <br/>
                                 Lua Lanes is published under the same <a href="http://en.wikipedia.org/wiki/MIT_License">MIT license</a> as Lua 5.1, 5.2, 5.3 and 5.4.
                         </p>
 
                         <p>
-                                This document was revised on 8-Feb-22, and applies to version <tt>3.16.0</tt>.
+                                This document was revised on 9-Aug-23, and applies to version <tt>3.16.1</tt>.
                         </p>
                 </font>
         </center>
@@ -338,9 +338,9 @@
                                 <tt>nil</tt>/<tt>"protected"</tt>/function
                         </td>
                         <td>
-                                (Since v3.13.0)<br/>
-                                If <tt>nil</tt>, Lua states are created with <tt>lua_newstate()</tt> and reuse the allocator from the master state.<br/>
-                                If <tt>"protected"</tt>, The default allocator obtained from <tt>lua_getallocf()</tt> in the master state is wrapped inside a critical section and used in all newly created states.<br/>
+                                (Since v3.13.0)<br />
+                                If <tt>nil</tt>, Lua states are created with <tt>lua_newstate()</tt> and reuse the allocator from the master state.<br />
+                                If <tt>"protected"</tt>, The default allocator obtained from <tt>lua_getallocf()</tt> in the master state is wrapped inside a critical section and used in all newly created states.<br />
                                 If a <tt>function</tt>, this function is called prior to creating the state. It should return a full userdata containing the following structure:
                                 <table border="1" bgcolor="#E0E0FF" cellpadding="10" style="width:50%">
                                         <tr>
@@ -356,6 +356,22 @@
                 </tr>
 
                 <tr valign=top>
+                        <td id="internal_allocator">
+                                <code>.internal_allocator</code>
+                        </td>
+                        <td>
+                                <tt>"libc"</tt>/<tt>"allocator"</tt>
+                        </td>
+                        <td>
+                                (Since v3.16.1)<br />
+                                Controls which allocator is used for Lanest internal allocations (for keeper and deep userdata management).
+                                If <tt>"libc"</tt>, Lanes uses <tt>realloc</tt> and <tt>free</tt>.<br />
+                                If <tt>"allocator"</tt>, Lanes uses whatever was obtained from the <tt>"allocator"</tt> setting.<br />
+                                This option is mostly useful for embedders that want control all memory allocations, but have issues when Lanes tries to use the Lua State allocator for internal purposes (especially with LuaJIT).
+                        </td>
+                </tr>
+
+                <tr valign=top>
                         <td id="demote_full_userdata">
                                 <code>.demote_full_userdata</code>
                         </td>
@@ -390,18 +406,18 @@
                         </td>
                         <td>
                                 If provided, will be called in every created Lua state right after initializing the base libraries.
-                                <br/>
+                                <br />
                                 Keeper states will call it as well, but only if it is a C function (keeper states are not able to execute any user Lua code).
-                                <br/>
+                                <br />
                                 Typical usage is twofold:
                                 <ul>
                                         <li>Tweak <tt>package.loaders</tt></li>
                                         <li>Load some additional C functions in the global space (of course only a C function will be able to do this).</li>
                                 </ul>
                                 That way, all changes in the state can be properly taken into account when building the function lookup database. Default is <tt>nil</tt>.
-                                <br/>
+                                <br />
                                 (Since version 3.7.6) If <tt>on_state_create()</tt> is a Lua function, it will be transfered normally before the call.
-                                <br/>
+                                <br />
                                 If it is a C function, a C closure will be reconstructed in the created state from the C pointer. Lanes will raise an error if the function has upvalues.
                         </td>
                 </tr>