* process exit change: close everything at GC when main state closes, not when atexit() handlers are processed

   * Lua 5.2-style module:
      * module() is no longer used to implement lanes.lua
      * a global "lanes" variable is no longer created when the module is required
      * the Lanes module table is returned instead
   * Lanes must be initialized before used:
      * the first occurence of 'require "lanes"' produces a minimal interface that only contains a configure() function
      * the remainder of the interface is made available once this function is called
      * subsequent calls to configure() do nothing
      * configure() controls the number of keeper states and the startup of timers
   * LuaJIT 2 compatibility
      * non-Lua functions are no longer copied by creating a C closure from a C pointer, but through 2-way lookup tables
      * this means that if a lane function body pulls non-Lua functions, the lane generator description must contain the list of libraries and modules that exports them
      * introduces a change in configuration .globals management: contents are copied *after* std libs are loaded
      * new .required configuration entry to list modules that must be require()'ed before lane body is transferred
   * lane:cancel() wakes up waiting lindas like what is done at lane shutdown

1 files changed, 3 insertions, 1 deletions

diff --git a/ABOUT b/ABOUT
index 81cf640..260fb5c 100644
--- a/ABOUT
+++ b/ABOUT
@@ -14,4 +14,6 @@ in the manual).
 
 Lua Lanes has been optimized for performance, and provides around 50-60%
 speed increase when running heavily threaded applications on dual core
-processors (compared to running a non-threaded plain Lua implementation). 
+processors (compared to running a non-threaded plain Lua implementation).
+
+Starting with version 3.0, Lanes is compatible with LuaJIT 2.
\ No newline at end of file