17 files changed, 151 insertions, 160 deletions

diff --git a/docs/index.html b/docs/index.html
index 73753d7..5f9a0fb 100644
--- a/docs/index.html
+++ b/docs/index.html
@@ -63,9 +63,9 @@
 
                 <font size="-1">
                         <p>
-                                <br/>
+                                <br />
                                 <i>Copyright &copy; 2007-24 Asko Kauppi, Benoit Germain. All rights reserved.</i>
-                                <br/>
+                                <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>
 
@@ -184,7 +184,7 @@
 </table>
 <p>
         <tt>luaopen_lanes_embedded</tt> leaves the module table on the stack. <a href="#initialization"><tt>lanes.configure()</tt></a> must still be called in order to use Lanes.
-        <br/>
+        <br />
         If <tt>_luaopen_lanes</tt> is <tt>nullptr</tt>, a default loader will simply attempt the equivalent of <tt>luaL_dofile(L, "lanes.lua")</tt>.
 </p>
 
@@ -197,17 +197,17 @@
         <tr>
                         <td>
                                 <pre>   #include "lanes.h"</pre>
-                                <br/>
+                                <br />
                                 <pre>   int load_lanes_lua(lua_State* L)</pre>
                                 <pre>   {</pre>
                                 <pre>           // retrieve lanes.lua from wherever it is stored and return the result of its execution</pre>
                                 <pre>           // trivial example 1:</pre>
                                 <pre>           luaL_dofile(L, "lanes.lua");</pre>
-                                <br/>
+                                <br />
                                 <pre>           // trivial example 2:</pre>
                                 <pre>           luaL_dostring(L, bin2c_lanes_lua);</pre>
                                 <pre>   }</pre>
-                                <br/>
+                                <br />
                                 <pre>   void embed_lanes(lua_State* L)</pre>
                                 <pre>   {</pre>
                                 <pre>           // we need base libraries for Lanes for work</pre>
@@ -219,7 +219,7 @@
                                 <pre>           // another example with a custom loader</pre>
                                 <pre>           luaopen_lanes_embedded(L, load_lanes_lua);</pre>
                                 <pre>           lua_pop(L, 1);</pre>
-                                <br/>
+                                <br />
                                 <pre>           // a little test to make sure things work as expected</pre>
                                 <pre>           luaL_dostring(L, "local lanes = require 'lanes'.configure{with_timers = false}; local l = lanes.linda()");</pre>
                                 <pre>   }</pre>
@@ -240,26 +240,25 @@
 <table border="1" bgcolor="#FFFFE0" cellpadding="10" style="width:50%">
         <tr>
                 <td>
-                        <pre>   local lanes = require "lanes".configure()</pre>
+                        <pre>   local lanes = require "lanes".configure(options|nil)</pre>
                 </td>
         </tr>
 </table>
 
 <p>
-        Requiring the module follows Lua 5.2+ rules: the module is not available under the global name "lanes", but has to be accessed through <tt>require</tt>'s return value.<br/>
+        Requiring the module follows Lua 5.2+ rules: the module is not available under the global name "lanes", but has to be accessed through <tt>require</tt>'s return value.<br />
         Lanes needs <tt>"base"</tt>, <tt>"string"</tt> and <tt>"table"</tt> to be initialized beforehand (plus <tt>"jit"</tt> for LuaJIT).
 </p>
 <p>
-        After lanes is required, it is necessary to call <tt>lanes.configure()</tt>, which is the only function exposed by the module at this point. Calling <tt>lanes.configure()</tt> will perform one-time initializations and make the rest of the API available.<br/>
-        At the same time, <tt>lanes.configure()</tt> itself will be replaced by another function that raises an error if called again with differing arguments, if any.
+        After lanes is required, it is recommended to call <tt>lanes.configure()</tt>, which is the only function exposed by the module at this point. Calling <tt>lanes.configure()</tt> will perform one-time initializations and make the rest of the API available.<br />
+        If <tt>lanes.configure()</tt> is not called before starting to use Lanes, it will be called automatically for you with default settings.<br />
+        Only the first occurence of <tt>require "lanes"</tt> must be followed by a call to <tt>lanes.configure()</tt>. From this point, a simple <tt>require "lanes"</tt> will be enough wherever you need to require lanes again.<br />
+        After being called, <tt>lanes.configure()</tt> itself is replaced by another function that does nothing with the argument it receives, in case it happens to be called again.
 </p>
 <p>
         Also, once Lanes is initialized, <tt>require()</tt> is replaced by another one that wraps it inside a mutex, both in the main state and in all created lanes. This prevents multiple thread-unsafe module initializations from several lanes to occur simultaneously.
         It remains to be seen whether this is actually useful or not: If a module is already threadsafe, protecting its initialization isn't useful. And if it is not, any parallel operation may crash without Lanes being able to do anything about it.
 </p>
-<p>
-        <b>IMPORTANT NOTE:</b> Only the first occurence of <tt>require "lanes"</tt> must be followed by a call to <tt>lanes.configure()</tt>. From this point, a simple <tt>require "lanes"</tt> will be enough wherever you need to require lanes again.
-</p>
 
 <p>
         <table border="1" bgcolor="#E0E0FF" cellpadding="10" style="width:50%">
@@ -285,8 +284,8 @@
                         </td>
                         <td>integer in [0,100]</td>
                         <td>
-                                Controls the number of "user" <a href="#keepers">Keeper state</a> used internally by <a href="#lindas">Linda</a>) objects to transfer data between lanes. Default is <tt>0</tt>.<br/>
-                                Lanes always creates at least one keeper state (of group <tt>0</tt> for the internal timer <a href="#lindas">Linda</a>. If <tt>nb_user_keepers</tt> is <tt>0</tt>, the other lindas you create will share this keeper by necessity.<br/>
+                                Controls the number of "user" <a href="#keepers">Keeper state</a> used internally by <a href="#lindas">Linda</a>) objects to transfer data between lanes. Default is <tt>0</tt>.<br />
+                                Lanes always creates at least one keeper state (of group <tt>0</tt> for the internal timer <a href="#lindas">Linda</a>. If <tt>nb_user_keepers</tt> is <tt>0</tt>, the other lindas you create will share this keeper by necessity.<br />
                                 If there is more than one <a href="#keepers">Keeper state</a> (in total), <a href="#lindas">Linda</a> creation must specify the group it belongs to.
                         </td>
                 </tr>
@@ -297,8 +296,8 @@
                         </td>
                         <td>integer</td>
                         <td>
-                                If &lt;0, GC runs automatically. This is the default.<br/>
-                                If 0, GC runs after *every* <a href="#keepers">Keeper</a> operation.<br/>
+                                If &lt;0, GC runs automatically. This is the default.<br />
+                                If 0, GC runs after *every* <a href="#keepers">Keeper</a> operation.<br />
                                 If &gt;0, <a href="#keepers">Keeper states</a> run GC manually with <tt>lua_gc(LUA_GCCOLLECT)</tt> whenever memory usage reported by <tt>lua_gc(LUA_GCCOUNT)</tt> reaches this threshold. Check is made after every operation (see <a href="#lindas">below</a>). If memory usage remains above threshold after the GC cycle, an error is raised.
                         </td>
                 </tr>
@@ -337,8 +336,8 @@
                                 <tt>nil</tt>/<tt>"protected"</tt>/function
                         </td>
                         <td>
-                                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 <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>
@@ -361,8 +360,8 @@
                         </td>
                         <td>
                                 Controls which allocator is used for Lanes internal allocations (for <a href="#keepers">Keeper state</a>, <a href="#lindas">Linda</a> and lane 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/>
+                                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>
@@ -388,16 +387,16 @@
                                 function/<tt>nil</tt>
                         </td>
                         <td>
-                                If provided, will be called in every created Lua state right after initializing the base libraries, with a single string argument, either <tt>"lane"</tt> or <tt>"keeper"</tt>.<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.<br/>
-                                Keeper states will call it as well, but only if it is a C function (<a href="#keepers">Keeper states</a> are not able to execute any user Lua code).<br/>
+                                If provided, will be called in every created Lua state right after initializing the base libraries, with a single string argument, either <tt>"lane"</tt> or <tt>"keeper"</tt>.<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.<br />
+                                Keeper states will call it as well, but only if it is a C function (<a href="#keepers">Keeper states</a> are not able to execute any user Lua code).<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/>
-                                If <tt>on_state_create()</tt> is a Lua function, it will be transfered normally before the call.<br/>
+                                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 />
+                                If <tt>on_state_create()</tt> is a Lua function, it will be transfered normally before the call.<br />
                         </td>
                 </tr>
 
@@ -439,9 +438,9 @@
 
 <p>
         Once Lanes is configured, one should register with Lanes the modules exporting functions that will be transferred either during lane generation or through <a href="#lindas">lindas</a>.
-        <br/>
+        <br />
         Use <tt>lanes.require()</tt> for this purpose. This will call the original <tt>require()</tt>, then add the result to the lookup databases.
-        <br/>
+        <br />
         It is also possible to register a given module with <tt>lanes.register()</tt>. This function will raise an error if the registered module is not a function or table.
 </p>
 
@@ -469,9 +468,9 @@
 </p>
 
 <p>
-        An error will be raised if you attempt to do this from inside a lane, or on bad arguments (non-function, or too many arguments).<br/>
-        Only the last registered finalizer is kept. It can be cleared by passing <tt>nil</tt> or nothing.<br/>
-        The installed function is called after all free-running lanes are terminated, but before lindas become unusable.<br/>
+        An error will be raised if you attempt to do this from inside a lane, or on bad arguments (non-function, or too many arguments).<br />
+        Only the last registered finalizer is kept. It can be cleared by passing <tt>nil</tt> or nothing.<br />
+        The installed function is called after all free-running lanes are terminated, but before lindas become unusable.<br />
         If an error occurs inside this finalizer, it is silently swallowed, since it happens only during state shutdown, and you can't do anything about it.
 </p>
 
@@ -485,17 +484,17 @@
 <table border=1 bgcolor="#FFFFE0" cellpadding="10" style="width:50%">
         <tr>
                 <td>
-                        <pre>   local lanes = require "lanes".configure()</pre>
-                        <br/>
+                        <pre>   local lanes = require "lanes"</pre>
+                        <br />
                         <pre>   f = lanes.gen(function(n) return 2 * n end)</pre>
                         <pre>   a = f(1)</pre>
                         <pre>   b = f(2)</pre>
-                        <br/>
+                        <br />
                         <pre>   print(a[1], b[1])     -- 2    4</pre>
                 </td>
         </tr>
 </table>
-<br/>
+<br />
 <table border=1 bgcolor="#E0E0FF" cellpadding="10" style="width:50%">
         <tr>
                 <td>
@@ -507,7 +506,7 @@
 
 <p>
         The function returned by <tt>lanes.gen()</tt> is a "generator" for launching any number of lanes. They will share code, options, initial globals, but the particular arguments may vary. Only calling the generator function actually launches a lane, and provides a handle for controlling it.
-        <br/>
+        <br />
         Alternatively, <tt>lane_func</tt> may be a string, in which case it will be compiled in the lane. This was to be able to launch lanes with older versions of LuaJIT, which didn't not support <tt>lua_dump</tt>, used internally to transfer functions to the lane.
 </p>
 
@@ -680,7 +679,7 @@
 </p>
 
 <p>
-        Any non-<tt>nil</tt> value causes initialization of <tt>"base"</tt> and <tt>"jit"</tt> (the latter only for LuaJIT-based builds).<br/>
+        Any non-<tt>nil</tt> value causes initialization of <tt>"base"</tt> and <tt>"jit"</tt> (the latter only for LuaJIT-based builds).<br />
         Initializing the standard libs takes a bit of time at each lane invocation. This is the main reason why "no libraries" is the default.
 </p>
 
@@ -702,7 +701,7 @@
                         </td>
                         <td>table</td>
                         <td>
-                                Sets the globals table for the launched threads. This can be used for giving them constants. The key/value pairs of <tt>table</tt> are transfered in the lane globals after the libraries have been loaded and the modules required.<br/>
+                                Sets the globals table for the launched threads. This can be used for giving them constants. The key/value pairs of <tt>table</tt> are transfered in the lane globals after the libraries have been loaded and the modules required.<br />
                                 The global values of different lanes are in no manner connected; modifying one will only affect the particular lane.
                         </td>
                 </tr>
@@ -715,7 +714,7 @@
                                 Lists modules that have to be required in order to be able to transfer functions they exposed. Non-Lua functions are <a href="#function_notes">searched in lookup tables</a>.
                                 These tables are built from the modules listed here. <tt>required</tt> must be an array of strings, each one being the name of a module to be required. Each module is required with <tt>require()</tt> before the lanes function is invoked.
                                 So, from the required module's point of view, requiring it manually from inside the lane body or having it required this way doesn't change anything. From the lane body's point of view, the only difference is that a module not creating a global won't be accessible.
-                                Therefore, a lane body will also have to require a module manually, but this won't do anything more (see Lua's <tt>require</tt> documentation). <br/>
+                                Therefore, a lane body will also have to require a module manually, but this won't do anything more (see Lua's <tt>require</tt> documentation). <br />
                                 ATTEMPTING TO TRANSFER A FUNCTION REGISTERED BY A MODULE NOT LISTED HERE WILL RAISE AN ERROR.
                         </td>
                 </tr>
@@ -725,8 +724,8 @@
                         </td>
                         <td>string</td>
                         <td>
-                                Sets the error reporting mode. One of <tt>"minimal"</tt> (the default), <tt>"basic"</tt>, <tt>"extended"</tt>.<br/>
-                                <tt>"minimal"</tt> yields only the location of the error.<br/>
+                                Sets the error reporting mode. One of <tt>"minimal"</tt> (the default), <tt>"basic"</tt>, <tt>"extended"</tt>.<br />
+                                <tt>"minimal"</tt> yields only the location of the error.<br />
                                 The other 2 yield a full stack trace, with different amounts of data extracted from the debug infos. See <a href="#results">Results</a>.
                         </td>
                 </tr>
@@ -755,8 +754,8 @@
                         <td>integer</td>
                         <td>
                                 The priority of lanes generated in the range -3..+3 (default is 0).
-                                These values are a mapping over the actual priority range of the underlying implementation.<br/>
-                                Implementation and dependability of priorities varies by platform. Especially Linux kernel 2.6 is not supporting priorities in user mode.<br/>
+                                These values are a mapping over the actual priority range of the underlying implementation.<br />
+                                Implementation and dependability of priorities varies by platform. Especially Linux kernel 2.6 is not supporting priorities in user mode.<br />
                                 A lane can also change its own thread priority dynamically with <a href="#priority"><tt>lanes.set_thread_priority()</tt></a>.
                         </td>
                 </tr>
@@ -766,7 +765,7 @@
                         </td>
                         <td> table</td>
                         <td>
-                                Specifying it when <code>libs_str</code> doesn't cause the <code>package</code> library to be loaded will generate an error.<br/>
+                                Specifying it when <code>libs_str</code> doesn't cause the <code>package</code> library to be loaded will generate an error.<br />
                                 If not specified, the created lane will receive the current values of <tt>package</tt>. Only <tt>path</tt>, <tt>cpath</tt>, <tt>preload</tt> and <tt>loaders</tt> (Lua 5.1)/<tt>searchers</tt> (Lua 5.2) are transfered.
                         </td>
                 </tr>
@@ -774,14 +773,14 @@
 
 <p>
         Each lane gets a global function <tt>set_debug_threadname()</tt> that it can use anytime to do as the name says. Supported debuggers are Microsoft Visual Studio (for the C side) and <a href="https://github.com/unknownworlds/decoda">Decoda</a> (for the Lua side).<br />
-        Change <tt>HAVE_DECODA_SUPPORT()</tt> in <tt>lanesconf.h</tt> to enable the Decoda support, that sets a special global variable <tt>decoda_name</tt> in the lane's state.<br/>
-        The name is stored inside the Lua state registry so that it is available for error reporting. Changing <tt>decoda_name</tt> doesn't affect this hidden name or the OS thread name reported by MSVC.<br/>
+        Change <tt>HAVE_DECODA_SUPPORT()</tt> in <tt>lanesconf.h</tt> to enable the Decoda support, that sets a special global variable <tt>decoda_name</tt> in the lane's state.<br />
+        The name is stored inside the Lua state registry so that it is available for error reporting. Changing <tt>decoda_name</tt> doesn't affect this hidden name or the OS thread name reported by MSVC.<br />
         When Lanes is initialized by the first <a href="#initialization"><tt>lanes.configure()</tt></a> call, <tt>"main"</tt> is stored in the registry in the same fashion (but <tt>decoda_name</tt> and the OS thread name are left unchanged).<br />
         The lane also has a method <tt>lane:get_debug_threadname()</tt> that gives access to that name from the caller side (returns <tt>"&lt;unnamed&gt;"</tt> if unset, <tt>"&lt;closed&gt;"</tt> if the internal Lua state is closed).
 </p>
 
 <p>
-        If a lane body pulls a C function imported by a module required before Lanes itself (thus not through a hooked <tt>require</tt>), the lane generator creation will raise an error.
+        If a lane body pulls a C function imported by a module required before Lanes itself (thus not through a hooked <tt>require()</tt>), the lane generator creation will raise an error.
         The function name it shows is a path where it was found by scanning <tt>_G</tt> and the registry. As a utility, the name guessing functionality is exposed as such:
 
         <table border="1" bgcolor="#E0E0FF" cellpadding="10" style="width:50%">
@@ -823,7 +822,7 @@
         </table>
 <p>
         Besides setting a default priority in the generator <a href="#generator_settings">settings</a>, each thread can change its own priority at will. This is also true for the main Lua state.
-        <br/>
+        <br />
         The priority must be in the range <tt>[-3,+3]</tt>.
 </p>
 
@@ -886,53 +885,53 @@
                         </td>
                 </tr>
                 <tr>
-                        <td/>
+                        <td />
                         <td>
                                 <tt>
                                         "running"
                                 </tt>
                         </td>
-                        <td/>
+                        <td />
                         <td>
                                 running, not suspended on a <a href="#lindas">Linda</a> call.
                         </td>
                 </tr>
                 <tr>
-                        <td/>
+                        <td />
                         <td>
                                 <tt>"waiting"</tt>
                         </td>
-                        <td/>
+                        <td />
                         <td>
                                 waiting at a <a href="#lindas">Linda</a> <tt>:receive()</tt> or <tt>:send()</tt>
                         </td>
                 </tr>
                 <tr>
-                        <td/>
+                        <td />
                         <td>
                                 <tt>"done"</tt>
                         </td>
-                        <td/>
+                        <td />
                         <td>
                                 finished executing (results are ready)
                         </td>
                 </tr>
                 <tr>
-                        <td/>
+                        <td />
                         <td>
                                 <tt>"error"</tt>
                         </td>
-                        <td/>
+                        <td />
                         <td>
                                 met an error (reading results will propagate it)
                         </td>
                 </tr>
                 <tr>
-                        <td/>
+                        <td />
                         <td>
                                 <tt>"cancelled"</tt>
                         </td>
-                        <td/>
+                        <td />
                         <td>
                                 received <a href="#cancelling">cancellation</a> and finished itself.
                         </td>
@@ -959,7 +958,7 @@
 
 <p>
         Only available if lane tracking is enabled by setting <a href="#track_lanes"><tt>track_lanes</tt></a>.
-        <br/>
+        <br />
         Returns an array table where each entry is a table containing a lane's name and status. Returns <tt>nil</tt> if no lane is running.
 </p>
 
@@ -982,7 +981,7 @@
 
 <p>
         Makes sure lane has finished, and gives its first (maybe only) return value. Other return values will be available in other <tt>lane_h</tt> indices.
-        <br/>
+        <br />
         If the lane ended in an error, it is propagated to master state at this place.
 </p>
 
@@ -991,14 +990,14 @@
 </pre></td></tr></table>
 
 <p>
-        <tt>timeout</tt> is an optional number &gt= 0 (the default if unspecified).<br/>
-        Waits until the lane finishes, or <tt>timeout</tt> seconds have passed.<br/>
-        Unlike in reading the results in table fashion, errors are not propagated.<br/>
+        <tt>timeout</tt> is an optional number &gt= 0 (the default if unspecified).<br />
+        Waits until the lane finishes, or <tt>timeout</tt> seconds have passed.<br />
+        Unlike in reading the results in table fashion, errors are not propagated.<br />
         Possible return values are:
         <ul>
                 <li><tt>nil, "timeout"</tt> on timeout.</li>
                 <li>
-                        <tt>nil,err,stack_tbl</tt> if the lane hit an error. The contents of <tt>stack_tbl</tt> change with <a href="#.error_trace_level"><tt>error_trace_level</tt></a>.<br/>
+                        <tt>nil,err,stack_tbl</tt> if the lane hit an error. The contents of <tt>stack_tbl</tt> change with <a href="#.error_trace_level"><tt>error_trace_level</tt></a>.<br />
                         <ul>
                                 <li><tt>"minimal"</tt>: <tt>stack_tbl</tt> is <tt>nil</tt>.</li>
                                 <li><tt>"basic"</tt>: <tt>stack_tbl</tt> is an array of <tt>"&lt;filename&gt;:&lt;line&gt;"</tt> strings. You can use <tt>table.concat()</tt> to format it to your liking (or just ignore it).</li>
@@ -1012,7 +1011,7 @@
 </p>
 
 <table border=1 bgcolor="#FFFFE0" cellpadding="10" style="width:50%"><tr><td><pre>
-        local lanes = require "lanes".configure()
+        local lanes = require "lanes"
 
         f = lanes.gen(function() error "!!!" end)
         a = f(1)
@@ -1030,7 +1029,7 @@
 </p>
 
 <table border=1 bgcolor="#FFFFE0" cellpadding="10" style="width:50%"><tr><td><pre>
-        local lanes = require "lanes".configure()
+        local lanes = require "lanes"
 
         local sync_linda = lanes.linda()
         f = lanes.gen(function() dostuff() sync_linda:send("done", true) end)
@@ -1053,25 +1052,25 @@
 
 <p>
         <tt>timeout</tt> is an optional number &gt= 0. Defaults to 0 if left unspecified or <tt>nil</tt>.
-        <br/>
+        <br />
         <tt>cancel()</tt> sends a cancellation request to the lane.
-        <br/>
+        <br />
         First argument is a <tt>mode</tt> can be one of <tt>"hard"</tt>, <tt>"soft"</tt>, <tt>"call"</tt>, <tt>"ret"</tt>, <tt>"line"</tt>, <tt>"count"</tt>.
         If <tt>mode</tt> is not specified, it defaults to <tt>"hard"</tt>.
         If <tt>wake_lane</tt> is <tt>true</tt>, the lane is also signalled so that execution returns from any pending <a href="#lindas">Linda</a> operation. <a href="#lindas">Linda</a> operations detecting the cancellation request return <tt>lanes.cancel_error</tt>.
 </p>
 <p>
-        If <tt>mode</tt> is <tt>"soft"</tt>, cancellation will only cause <tt>cancel_test()</tt> to return <tt>true</tt>, so that the lane can cleanup manually.<br/>
+        If <tt>mode</tt> is <tt>"soft"</tt>, cancellation will only cause <tt>cancel_test()</tt> to return <tt>true</tt>, so that the lane can cleanup manually.<br />
 </p>
 <p>
-        If <tt>mode</tt> is <tt>"hard"</tt>, waits for the request to be processed, or a timeout to occur. <a href="#lindas">Linda</a> operations detecting the cancellation request will raise a special cancellation error (meaning they won't return in that case).<br/>
+        If <tt>mode</tt> is <tt>"hard"</tt>, waits for the request to be processed, or a timeout to occur. <a href="#lindas">Linda</a> operations detecting the cancellation request will raise a special cancellation error (meaning they won't return in that case).<br />
         <tt>wake_lane</tt> defaults to <tt>true</tt>, and <tt>timeout</tt> defaults to 0 if not specified.
 </p>
 <p>
         Other values of <tt>mode</tt> will asynchronously install the corresponding hook, then behave as <tt>"hard"</tt>.
 </p>
 <p>
-        Returns <tt>true, lane_h.status</tt> if lane was already done (in <tt>"done"</tt>, <tt>"error"</tt> or <tt>"cancelled"</tt> status), or the cancellation was fruitful within <tt>timeout_secs</tt> timeout period.<br/>
+        Returns <tt>true, lane_h.status</tt> if lane was already done (in <tt>"done"</tt>, <tt>"error"</tt> or <tt>"cancelled"</tt> status), or the cancellation was fruitful within <tt>timeout_secs</tt> timeout period.<br />
         Returns <tt>false, "timeout"</tt> otherwise.
 </p>
 <p>
@@ -1079,11 +1078,11 @@
 </p>
 <p>
         Cancellation is tested <u>before</u> going to sleep in <tt>receive()</tt> or <tt>send()</tt> calls and after executing <tt>cancelstep</tt> Lua statements. A pending <tt>receive()</tt>or <tt>send()</tt> call is awakened.
-        <br/>
+        <br />
         This means the execution of the lane will resume although the operation has not completed, to give the lane a chance to detect cancellation (even in the case the code waits on a <a href="#lindas">Linda</a> with infinite timeout).
-        <br/>
+        <br />
         The code should be able to handle this situation appropriately if required (in other words, it should gracefully handle the fact that it didn't receive the expected values).
-        <br/>
+        <br />
         It is also possible to manually test for cancel requests with <tt>cancel_test()</tt>.
 </p>
 
@@ -1146,7 +1145,7 @@
 </p>
 
 <table border="1" bgcolor="#FFFFE0" cellpadding="10" style="width:50%"><tr><td><pre>
-        local lanes = require "lanes".configure()
+        local lanes = require "lanes"
 
         local linda = lanes.linda("my linda")
 
@@ -1201,8 +1200,8 @@
 </pre></td></tr></table>
 
 <p>
-        Converting the Linda to a string will yield the provided name prefixed by <tt>"Linda: "</tt>.<br/>
-        If <tt>opt_name</tt> is omitted, it will evaluate to an hexadecimal number uniquely representing that Linda when the Linda is converted to a string. The value is the same as returned by <tt>linda:deep()</tt>.<br/>
+        Converting the Linda to a string will yield the provided name prefixed by <tt>"Linda: "</tt>.<br />
+        If <tt>opt_name</tt> is omitted, it will evaluate to an hexadecimal number uniquely representing that Linda when the Linda is converted to a string. The value is the same as returned by <tt>linda:deep()</tt>.<br />
         If <tt>opt_name</tt> is <tt>"auto"</tt>, Lanes will try to construct a name from the source location that called <tt>lanes.linda()</tt>. If that fails, the Linda name will be <tt>"&lt;unresolved&gt;"</tt>.
 </p>
 
@@ -1211,9 +1210,9 @@
 </pre></td></tr></table>
 
 <p>
-        By default, queue sizes are unlimited but limits can be enforced using the <tt>limit()</tt> method. This can be useful to balance execution speeds in a producer/consumer scenario. <tt>nil</tt> removes the limit.<br/>
-        A limit of 0 is allowed to block everything.<br/>
-        If the key was full but the limit change added some room, <tt>limit()</tt> returns <tt>true</tt> and the Linda is signalled so that <tt>send()</tt>-blocked threads are awakened.<br/>
+        By default, queue sizes are unlimited but limits can be enforced using the <tt>limit()</tt> method. This can be useful to balance execution speeds in a producer/consumer scenario. <tt>nil</tt> removes the limit.<br />
+        A limit of 0 is allowed to block everything.<br />
+        If the key was full but the limit change added some room, <tt>limit()</tt> returns <tt>true</tt> and the Linda is signalled so that <tt>send()</tt>-blocked threads are awakened.<br />
 </p>
 
 <table border="1" bgcolor="#E0E0FF" cellpadding="10" style="width:50%"><tr><td><pre>
@@ -1221,7 +1220,7 @@
 </pre></td></tr></table>
 
 <p>
-        Timeouts are given in seconds (&gt= 0, millisecond accuracy) or <tt>nil</tt>. Timeout can be omitted only if the first key is not a number (then it is equivalent to an infinite duration).<br/>
+        Timeouts are given in seconds (&gt= 0, millisecond accuracy) or <tt>nil</tt>. Timeout can be omitted only if the first key is not a number (then it is equivalent to an infinite duration).<br />
         Each key acts as a FIFO queue. There is no limit to the number of keys a Linda may contain. Different Lindas can have identical keys, which are totally unrelated.
 </p>
 
@@ -1231,8 +1230,8 @@
 </p>
 
 <p>
-        If no data is provided after the key, <tt>send()</tt> raises an error.<br/>
-        Also, if <tt>linda.null</tt> or <tt>lanes.null</tt> is sent as data in a Linda, it will be read as a <tt>nil</tt>.<br/>
+        If no data is provided after the key, <tt>send()</tt> raises an error.<br />
+        Also, if <tt>linda.null</tt> or <tt>lanes.null</tt> is sent as data in a Linda, it will be read as a <tt>nil</tt>.<br />
         <tt>send()</tt> return values can be:
         <ul>
                 <li><tt>true</tt> on success.</li>
@@ -1280,19 +1279,19 @@
 </pre></td></tr></table>
 
 <p>
-        The table access methods are for accessing a slot without queuing or consuming. They can be used for making shared tables of storage among the lanes.<br/>
-        Writing to a slot never blocks because it ignores the limit. It overwrites existing value and clears any possible queued entries.<br/>
-        Reading doesn't block either because <tt>get()</tt> returns whatever is available (which can be nothing), up to the specified count.<br/>
+        The table access methods are for accessing a slot without queuing or consuming. They can be used for making shared tables of storage among the lanes.<br />
+        Writing to a slot never blocks because it ignores the limit. It overwrites existing value and clears any possible queued entries.<br />
+        Reading doesn't block either because <tt>get()</tt> returns whatever is available (which can be nothing), up to the specified count.<br />
         Table access and <tt>send()</tt>/<tt>receive()</tt> can be used together; reading a slot essentially peeks the next outcoming value of a queue.
 </p>
 
 <p>
-        <tt>set()</tt> signals the Linda for write if a value is stored. If nothing special happens, <tt>set() </tt>returns nothing.<br/>
+        <tt>set()</tt> signals the Linda for write if a value is stored. If nothing special happens, <tt>set() </tt>returns nothing.<br />
         If the key was full but the new data count of the key after <tt>set()</tt> is below its limit, <tt>set()</tt> returns <tt>true</tt> and the Linda is also signaled for read so that <tt>send()</tt>-blocked threads are awakened.
 </p>
 
 <p>
-        <tt>set()</tt> can write several values at the specified key, writing <tt>nil</tt> values is now possible, and clearing the contents at the specified key is done by not providing any value.<br/>
+        <tt>set()</tt> can write several values at the specified key, writing <tt>nil</tt> values is now possible, and clearing the contents at the specified key is done by not providing any value.<br />
         Also, <tt>get()</tt> can read several values at once. If the key contains no data, <tt>get()</tt> returns no value. This can be used to separate the case when reading stored <tt>nil</tt> values.
 </p>
 
@@ -1305,10 +1304,10 @@
 </pre></td></tr></table>
 
 <p>
-        Returns some information about the contents of the Linda.<br/>
-        If no key is specified, and the Linda is empty, returns nothing.<br/>
-        If no key is specified, and the Linda is not empty, returns a table of key/count pairs that counts the number of items in each of the exiting keys of the Linda. This count can be 0 if the key has been used but is empty.<br/>
-        If a single key is specified, returns the number of pending items, or nothing if the key is unknown.<br/>
+        Returns some information about the contents of the Linda.<br />
+        If no key is specified, and the Linda is empty, returns nothing.<br />
+        If no key is specified, and the Linda is not empty, returns a table of key/count pairs that counts the number of items in each of the exiting keys of the Linda. This count can be 0 if the key has been used but is empty.<br />
+        If a single key is specified, returns the number of pending items, or nothing if the key is unknown.<br />
         If more than one key is specified, return a table of key/count pairs for the known keys.
 </p>
 
@@ -1317,7 +1316,7 @@
 </pre></td></tr></table>
 
 <p>
-        Returns a table describing the full contents of a Linda, or <tt>nil</tt> if the Linda wasn't used yet.<br/>
+        Returns a table describing the full contents of a Linda, or <tt>nil</tt> if the Linda wasn't used yet.<br />
         If Decoda support is enabled with <tt>HAVE_DECODA_SUPPORT()</tt>, <a Linda metatable contain a <tt>__towatch</tt> special function that generates a similar table used for debug display.
 </p>
 
@@ -1327,8 +1326,8 @@
 
 <p>
         Signals the Linda so that lanes waiting for read, write, or both, wake up.
-        All Linda operations (including <tt>get()</tt> and <tt>set()</tt>) will return <tt>lanes.cancel_error</tt> as when the calling lane is <a href="#cancelling">soft-cancelled</a> as long as the Linda is marked as cancelled.<br/>
-        <tt>"none"</tt> reset the Linda's cancel status, but doesn't signal it.<br/>
+        All Linda operations (including <tt>get()</tt> and <tt>set()</tt>) will return <tt>lanes.cancel_error</tt> as when the calling lane is <a href="#cancelling">soft-cancelled</a> as long as the Linda is marked as cancelled.<br />
+        <tt>"none"</tt> reset the Linda's cancel status, but doesn't signal it.<br />
         If not void, the lane's cancel status overrides the Linda's cancel status.
 </p>
 
@@ -1343,12 +1342,12 @@
 <h3 id="keepers">Granularity of using Lindas</h3>
 
 <p>
-        A Linda is a gateway to read and write data inside some hidden Lua states, called keeper states. Lindas are hashed to a fixed number of keeper states, which are a locking entity.<br/>
-        The data sent through a Linda is stored inside the associated keeper state in a Lua table where each Linda slot is the key to another table containing a FIFO for that slot.<br/>
-        Each keeper state is associated with an OS mutex, to prevent concurrent access to the keeper state. The Linda itself uses two signals to be made aware of operations occuring on it.<br/>
-        Whenever Lua code reads from or writes to a Linda, the mutex is acquired. If Linda limits don't block the operation, it is fulfilled, then the mutex is released.<br/>
-        If the Linda has to block, the mutex is released and the OS thread sleeps, waiting for a Linda operation to be signalled. When an operation occurs on the same Linda, possibly fufilling the condition, or a timeout expires, the thread wakes up.<br/>
-        If the thread is woken but the condition is not yet fulfilled, it goes back to sleep, until the timeout expires.<br/>
+        A Linda is a gateway to read and write data inside some hidden Lua states, called keeper states. Lindas are hashed to a fixed number of keeper states, which are a locking entity.<br />
+        The data sent through a Linda is stored inside the associated keeper state in a Lua table where each Linda slot is the key to another table containing a FIFO for that slot.<br />
+        Each keeper state is associated with an OS mutex, to prevent concurrent access to the keeper state. The Linda itself uses two signals to be made aware of operations occuring on it.<br />
+        Whenever Lua code reads from or writes to a Linda, the mutex is acquired. If Linda limits don't block the operation, it is fulfilled, then the mutex is released.<br />
+        If the Linda has to block, the mutex is released and the OS thread sleeps, waiting for a Linda operation to be signalled. When an operation occurs on the same Linda, possibly fufilling the condition, or a timeout expires, the thread wakes up.<br />
+        If the thread is woken but the condition is not yet fulfilled, it goes back to sleep, until the timeout expires.<br />
         When a lane is cancelled, the signal it is waiting on (if any) is signalled. In that case, the Linda operation will return <tt>lanes.cancel_error</tt>.
 </p>
 
@@ -1464,7 +1463,7 @@ On the other side, you need to use a common Linda for waiting for multiple keys.
 
 <p>
         A very simple way of sleeping when nothing else is available. Is implemented by attempting to read some data in an unused channel of the internal <a href="#lindas">Linda</a> used for timers (this <a href="#lindas">Linda</a> exists even when timers aren't enabled).
-        Default duration is 0, which should only cause a thread context switch.<br/>
+        Default duration is 0, which should only cause a thread context switch.<br />
         Return values should always be <tt>nil, "timeout"</tt> (or <tt>nil, lanes.cancel_error</tt> in case of interruption).
 </p>
 
@@ -1494,9 +1493,9 @@ On the other side, you need to use a common Linda for waiting for multiple keys.
 
 <p>
         The generated function acquires M tokens from the N available, or releases them if the value is negative. The acquiring call will suspend the lane, if necessary. Use <tt>M=N=1</tt> for a critical section lock (only one lane allowed to enter).
-        <br/>
+        <br />
         When passsing <tt>"try"</tt> as second argument when acquiring, then <tt>lock_func</tt> operates on the <a href="#lindas">Linda</a> with a timeout of 0 to emulate a TryLock() operation. If locking fails, <tt>lock_func</tt> returns <tt>false</tt>. <tt>"try"</tt> is ignored when releasing (as it it not expected to ever have to wait unless the acquisition/release pairs are not properly matched).
-        <br/>
+        <br />
         Upon successful lock/unlock, <tt>lock_func</tt> returns <tt>true</tt> (always the case when block-waiting for completion).
 </p>
 
@@ -1591,15 +1590,15 @@ On the other side, you need to use a common Linda for waiting for multiple keys.
 
 <p>
         Since functions are first class values, they don't have a name. All we know for sure is that when a C module registers some functions, they are accessible to the script that required the module through some exposed variables.
-        <br/>
+        <br />
         For example, loading the <tt>string</tt> base library creates a table accessible when indexing the global environment with key <tt>"string"</tt>. Indexing this table with <tt>"match"</tt>, <tt>"gsub"</tt>, etc. will give us a function.
-        <br/>
+        <br />
         When a lane generator creates a lane and performs initializations described by the list of base libraries and the list of required modules, it recursively scans the table created by the initialisation of the module, looking for all values that are C functions.
-        <br/>
+        <br />
         Each time a function is encountered, the sequence of keys that reached that function is contatenated in a (hopefully) unique name. The [name, function] and [function, name] pairs are both stored in a lookup table in all involved Lua states (main Lua state and lanes states).
-        <br/>
+        <br />
         Then when a function is transfered from one state to another, all we have to do is retrieve the name associated to a function in the source Lua state, then with that name retrieve the equivalent function that already exists in the destination state.
-        <br/>
+        <br />
         Note that there is no need to transfer upvalues, as they are already bound to the function registered in the destination state. (And in any event, it is not possible to create a closure from a C function pushed on the stack, it can only be created with a <tt>lua_CFunction</tt> pointer).
 </p>
 
@@ -1659,8 +1658,8 @@ On the other side, you need to use a common Linda for waiting for multiple keys.
 <h3 id="clonable_userdata">Clonable full userdata in your own apps</h3>
 <p>
         An alternative way of passing full userdata across lanes uses a new <tt>__lanesclone</tt> metamethod.
-        When a deep userdata is cloned, Lanes calls <tt>__lanesclone</tt> once, in the context of the source lane.<br/>
-        The call receives the clone and original as light userdata, plus the actual userdata size, as in <tt>clone:__lanesclone(original,size)</tt>, and should perform the actual cloning.<br/>
+        When a deep userdata is cloned, Lanes calls <tt>__lanesclone</tt> once, in the context of the source lane.<br />
+        The call receives the clone and original as light userdata, plus the actual userdata size, as in <tt>clone:__lanesclone(original,size)</tt>, and should perform the actual cloning.<br />
         A typical implementation would look like:
 <table border="1" bgcolor="#FFFFE0" cellpadding="10" style="width:50%"><tr><td><pre>
 static int clonable_lanesclone(lua_State* L)
@@ -1686,7 +1685,7 @@ static int clonable_lanesclone(lua_State* L)
 </p>
 
 <p>
-        <b>NOTE</b>: In the event the source userdata has uservalues, it is not necessary to create them for the clone, Lanes will handle their cloning.<br/>
+        <b>NOTE</b>: In the event the source userdata has uservalues, it is not necessary to create them for the clone, Lanes will handle their cloning.<br />
         Of course, more complex objects may require smarter cloning behavior than a simple <tt>memcpy</tt>. Also, the module initialisation code should make each metatable accessible from the module table itself as in:
 <table border="1" bgcolor="#FFFFE0" cellpadding="10" style="width:50%"><tr><td><pre>
 int luaopen_deep_test(lua_State* L)
@@ -1768,9 +1767,9 @@ static MyDeepFactory g_MyDeepFactory;
 </p>
 
 <p>
-        Deep userdata in transit inside <a href="#keepers">Keeper states</a> (sent in a <a href="#lindas">Linda</a> but not yet consumed) don't call <tt>deleteDeepObjectInternal</tt> and aren't considered by reference counting. The rationale is the following:<br/>
-        If some non-keeper state holds a deep userdata for some deep object, then even if the keeper collects its own deep userdata, it shouldn't be cleaned up since the refcount is not 0.<br/>
-        OTOH, if a keeper state holds the last deep userdata for some deep object, then no lane can do actual work with it. Deep userdata's <tt>factory()</tt> interface is never accessed from a keeper state.<br/>
+        Deep userdata in transit inside <a href="#keepers">Keeper states</a> (sent in a <a href="#lindas">Linda</a> but not yet consumed) don't call <tt>deleteDeepObjectInternal</tt> and aren't considered by reference counting. The rationale is the following:<br />
+        If some non-keeper state holds a deep userdata for some deep object, then even if the keeper collects its own deep userdata, it shouldn't be cleaned up since the refcount is not 0.<br />
+        OTOH, if a keeper state holds the last deep userdata for some deep object, then no lane can do actual work with it. Deep userdata's <tt>factory()</tt> interface is never accessed from a keeper state.<br />
         Therefore, Lanes can just call <tt>deleteDeepObjectInternal</tt> when the last non-keeper-held deep userdata is collected, as long as it doesn't do the same in a keeper state after that, since any remaining deep userdata in <a href="#keepers">Keeper states</a> now hold stale pointers.
 </p>
 
diff --git a/src/lanes.lua b/src/lanes.lua
index 07792b6..d890adf 100644
--- a/src/lanes.lua
+++ b/src/lanes.lua
@@ -758,7 +758,7 @@ local configure = function(settings_)
     -- Configure called so remove metatable from lanes
     lanesMeta.__metatable = nil -- unprotect the metatable
     setmetatable(lanes, nil) -- remove it
-    lanes.configure = nil -- no need to call configure() ever again
+    lanes.configure = function() return lanes end -- no need to configure anything again
 
     -- now we can configure Lanes core
     local settings = core.configure and core.configure(params_checker(settings_)) or core.settings
diff --git a/tests/appendud.lua b/tests/appendud.lua
index d0efb26..f510c8b 100644
--- a/tests/appendud.lua
+++ b/tests/appendud.lua
@@ -7,7 +7,6 @@
 -- Needs Lanes >= 2.0.3
 --
 local lanes = require "lanes"
-lanes.configure()
 
 local _tab = {
     beginupdate = function (this) print('tab.beginupdate') end;
diff --git a/tests/atomic.lua b/tests/atomic.lua
index 12bdf02..2de8f52 100644
--- a/tests/atomic.lua
+++ b/tests/atomic.lua
@@ -5,7 +5,6 @@
 --
 
 local lanes = require "lanes"
-lanes.configure()
 
 local linda= lanes.linda()
 local key= "$"
diff --git a/tests/basic.lua b/tests/basic.lua
index cad3764..bdad44c 100644
--- a/tests/basic.lua
+++ b/tests/basic.lua
@@ -7,7 +7,8 @@
 --      - ...
 --
 local config = { with_timers = false, strip_functions = false, internal_allocator = "libc"}
-local require_lanes_result_1, require_lanes_result_2 = require "lanes".configure(config)
+-- calling configure more than once should work (additional called are ignored)
+local require_lanes_result_1, require_lanes_result_2 = require "lanes".configure(config).configure()
 print("require_lanes_result:", require_lanes_result_1, require_lanes_result_2)
 local lanes = require_lanes_result_1
 
@@ -434,7 +435,7 @@ local function chunk2(linda)
     assert(config.strip_functions and info.short_src=="?" or string.match(info.short_src, "^.*basic.lua$"), "bad info.short_src")
     -- These vary so let's not be picky (they're there..)
     --
-    assert(info.linedefined == 419, "bad linedefined")   -- start of 'chunk2'
+    assert(info.linedefined == 420, "bad linedefined")   -- start of 'chunk2'
     assert(config.strip_functions and info.currentline==-1 or info.currentline > info.linedefined, "bad currentline")   -- line of 'debug.getinfo'
     assert(info.lastlinedefined > info.currentline, "bad lastlinedefined")   -- end of 'chunk2'
     local k,func= linda:receive("down")
diff --git a/tests/cyclic.lua b/tests/cyclic.lua
index 553d2a9..fd6d4a0 100644
--- a/tests/cyclic.lua
+++ b/tests/cyclic.lua
@@ -5,7 +5,6 @@
 --
 
 local lanes = require "lanes"
-lanes.configure()
 
 local table_concat= assert(table.concat)
 
diff --git a/tests/deadlock.lua b/tests/deadlock.lua
index c38ca13..bbbda8d 100644
--- a/tests/deadlock.lua
+++ b/tests/deadlock.lua
@@ -1,8 +1,10 @@
 -- this script tests the fix of a bug that could cause the mutex of a keeper state to remain locked
 -- see https://github.com/LuaLanes/lanes/commit/0cc1c9c9dcea5955f7dab921d9a2fff78c4e1729
 
-local lanes = require('lanes').configure{with_timers=false}
-local linda = lanes.linda "deadlock_linda"
+local lanes = require "lanes"
+
+-- Lua 5.1 compatibility
+local table_unpack = table.unpack or unpack
 
 local SLEEP = function(...)
     local k, v = lanes.sleep(...)
@@ -14,27 +16,28 @@ print "let's begin"
 local do_extra_stuff = true
 
 if do_extra_stuff then
-        -- just something to make send() succeed and receive() fail (any C function exposed by some module will do)
-        local payload = { lanes.require('socket').connect }
-
-        -- lane generator
-        local g = lanes.gen('*', function()
-                set_debug_threadname( "deadlock_lane")
-                -- wrapping inside pcall makes the Lanes module unaware that something went wrong
-                print( "In lane 1:", table.unpack{ pcall( linda.receive, linda, 'tmp')})
-                -- with the bug not fixed, and non-recursive mutexes, we can hang here
-                print( "In lane 2:", table.unpack{ pcall( linda.receive, linda, 'tmp')})
-                -- return something out of the lane
-                return 33, 55
-        end)
-
-        -- send payload twice. succeeds because sending stores a function identification string in the linda's keeper state
-        linda:send( 'tmp', payload, payload)
-        -- start the lane
-        local h = g()
-        -- wait for lane completion
-        local err, stack = h:join()
-        print( 'result of lane execution', err, stack)
+    local linda = lanes.linda "deadlock_linda"
+    -- just something to make send() succeed and receive() fail
+    local payload = { io.flush }
+
+    -- lane generator. don't initialize "io" base library so that it is not known in the lane
+    local g = lanes.gen('base,table', function()
+        set_debug_threadname( "deadlock_lane")
+        -- wrapping inside pcall makes the Lanes module unaware that something went wrong
+        print( "In lane 1:", table_unpack{ pcall( linda.receive, linda, 'tmp')})
+        -- with the bug not fixed, and non-recursive mutexes, we can hang here
+        print( "In lane 2:", table_unpack{ pcall( linda.receive, linda, 'tmp')})
+        -- return something out of the lane
+        return 33, 55
+    end)
+
+    -- send payload twice. succeeds because sending stores a function identification string in the linda's keeper state
+    linda:send( 'tmp', payload, payload)
+    -- start the lane
+    local h = g()
+    -- wait for lane completion
+    local err, stack = h:join()
+    print( 'result of lane execution', err, stack)
 end
 
 -- With the bug not fixed, the linda keeper's mutex is still acquired,
diff --git a/tests/ehynes.lua b/tests/ehynes.lua
index 9436c7d..cdcd5a5 100644
--- a/tests/ehynes.lua
+++ b/tests/ehynes.lua
@@ -2,7 +2,6 @@
 -- Test from <ehynes at dharmagaia.com>
 --
 local lanes = require "lanes"
-lanes.configure()
 
 local SLEEP = function(...)
     local k, v = lanes.sleep(...)
diff --git a/tests/fibonacci.lua b/tests/fibonacci.lua
index 0ff2f37..51e7137 100644
--- a/tests/fibonacci.lua
+++ b/tests/fibonacci.lua
@@ -12,7 +12,7 @@
 
 -- Need to say it's 'local' so it can be an upvalue
 --
-local lanes = require "lanes".configure()
+local lanes = require "lanes"
 
 local function WR(str)
     io.stderr:write( str.."\n" )
diff --git a/tests/hangtest.lua b/tests/hangtest.lua
index 6a9f7aa..0e44451 100644
--- a/tests/hangtest.lua
+++ b/tests/hangtest.lua
@@ -3,7 +3,6 @@
 --

 

 local lanes = require "lanes"

-lanes.configure()

 

 local function ret(b)

     return b

diff --git a/tests/irayo_closure.lua b/tests/irayo_closure.lua
index 3278d57..45189ec 100644
--- a/tests/irayo_closure.lua
+++ b/tests/irayo_closure.lua
@@ -11,7 +11,6 @@ e.g. { globals = { data = 1, func = function() useclosurehere() end } }"
 ]]
 
 local lanes = require "lanes"
-lanes.configure()
 
 local function testrun()
     assert( print )
diff --git a/tests/irayo_recursive.lua b/tests/irayo_recursive.lua
index fe722a3..88f4aab 100644
--- a/tests/irayo_recursive.lua
+++ b/tests/irayo_recursive.lua
@@ -1,4 +1,4 @@
-local lanes = require "lanes".configure()
+local lanes = require "lanes"
 --
 -- Bugs filed by irayo Jul-2008
 --
diff --git a/tests/launchtest.lua b/tests/launchtest.lua
index f3a6740..16db242 100644
--- a/tests/launchtest.lua
+++ b/tests/launchtest.lua
@@ -46,7 +46,6 @@ for k,v in pairs( argtable(...) ) do
 end
 
 local lanes = require "lanes"
-lanes.configure()
 
 local g= lanes.gen( LIBS, function(i) 
                         --io.stderr:write( i.."\t" )
diff --git a/tests/objects.lua b/tests/objects.lua
index 7668e45..61c280d 100644
--- a/tests/objects.lua
+++ b/tests/objects.lua
@@ -5,7 +5,6 @@
 --
 
 local lanes = require "lanes"
-lanes.configure()
 
 local linda= lanes.linda()
 
diff --git a/tests/parallel_os_calls.lua b/tests/parallel_os_calls.lua
index 7e7de26..8030d4c 100644
--- a/tests/parallel_os_calls.lua
+++ b/tests/parallel_os_calls.lua
@@ -1,4 +1,4 @@
-local lanes = require "lanes".configure()
+local lanes = require "lanes"
 print( os.date())
 local linda = lanes.linda()
 local l1 = lanes.gen("os,base", function() print "start sleeping" linda:receive(3, "null") print("finished_sleeping " .. os.date()) return true end)()
diff --git a/tests/pingpong.lua b/tests/pingpong.lua
index fdc60a6..3498f49 100644
--- a/tests/pingpong.lua
+++ b/tests/pingpong.lua
@@ -1,4 +1,4 @@
-local lanes = require 'lanes'.configure()
+local lanes = require "lanes"
 local q = lanes.linda()
 
 local pingpong = function(name, qr, qs, start)
diff --git a/tests/recursive.lua b/tests/recursive.lua
index 139f4c8..97b9c5b 100644
--- a/tests/recursive.lua
+++ b/tests/recursive.lua
@@ -12,14 +12,10 @@ local function func( depth )
     end
 
     local lanes = require "lanes"
-    -- lanes.configure() is available only at the first require()
-    if lanes.configure then
-                        lanes = lanes.configure{with_timers = false}
-                end
-    local lane= lanes.gen("*", func)( depth+1 )
+    local lane = lanes.gen("*", func)( depth+1 )
     return lane[1]
 end
 
 local v= func(0)
 assert(v=="done!")
-io.stderr:write("\n")
+io.stderr:write("TEST OK\n")