Skip to content
Lanes is a lightweight, native, lazy evaluating multithreading library for Lua 5.1 to 5.4.
C Lua C++ Makefile Batchfile CMake
Branch: master
Clone or download
benoit-germain Create manual_register.lua
New test sample to demonstrate on_state_create and manual function registration.
Latest commit 5add9b9 Dec 13, 2019
Type Name Latest commit message Commit time
Failed to load latest commit information.
deep_test Fix clonable userdata uservalue transfer Nov 30, 2018
docs Lane cancellation rework Apr 26, 2019
src Lane cancellation rework Apr 26, 2019
tests Create manual_register.lua Dec 13, 2019
ABOUT Update ABOUT Nov 30, 2018
BUGS removed fixed BUGS entries Sep 14, 2012
CHANGES Lane cancellation rework Apr 26, 2019
COPYRIGHT lanes version 3.2.0 Aug 22, 2012
Makefile Lane cancellation rework Apr 26, 2019
README protect_allocator configure option is gone, long live allocator (more… Nov 25, 2018
TODO Update TODO Oct 15, 2013 Changed idfunc signature and contract to clarify that fact it is not … Feb 12, 2011
lanes-3.14.0-0.rockspec Lane cancellation rework Apr 26, 2019
make-vc.cmd Update make-vc.cmd Dec 6, 2013
setup-vc.cmd * linda uses a fast FIFO implementation to speed up data exchanges Apr 18, 2011


Documentation is available online at
(should be the same as what is in the docs folder of the distribution).

  Usage on Windows:

For once, Win32 thread prioritazion scheme is actually a good one, and
it works. :)  Windows users, feel yourself as VIP citizens!!

  Windows / MSYS:

On MSYS, 'stderr' output seems to be buffered. You might want to make
it auto-flush, to help you track & debug your scripts. Like this:

    io.stderr:setvbuf "no"

Even after this, MSYS insists on linewise buffering; it will flush at
each newline only.

  Usage on Linux:

Linux NTPL 2.5 (Ubuntu 7.04) was used in the testing of Lua Lanes.

This document (
describes fairly well, what (all) is wrong with Linux threading, even today.

For other worthy links:

In short, you cannot use thread prioritation in Linux. Unless you run as
root, and I _truly_ would not recommend that. Lobby for yet-another thread
implementation for Linux, and mail -> about it. :)

CAVEAT: Anyone sufficiently knowledgeable with pthread scheduling is free to
contact me bnt DOT germain AT gmail DOT com)  with a suitable edit
if this no longer applies on more recent kernels.

  Usage on Mac OS X:

No real problems in OS X, _once_ everything is set up right...

In short, have your Lua core compiled with LUA_USE_DLOPEN and LUA_USE_POSIX
instead of the (default as of 5.1) LUA_DL_DYLD and LUA_USE_MACOSX. This is
crucial to have each module loaded only once (even if initialized separately
for each thread) and for the static & global variables within the modules to
actually be process-wide. Lua Lanes cannot live without...
Lua 5.2 is fine in that regard (check luaconf.h to be safe).

Another issue is making sure you only have _one_ Lua core. Your 'lua' binary
must link dynamically to a .dylib, it must _not_ carry a personal copy of Lua
core with itself. If it does, you will gain many mysterious malloc errors
when entering multithreading realm.

lua-xcode2(9473,0xa000ed88) malloc: ***  Deallocation of a pointer not malloced: 0xe9fc0; This could be a double free(), or free() called with the middle of an allocated block; Try setting environment variable MallocHelp to see tools to help debug

rm lua.o luac.o
gcc -dynamiclib -install_name /usr/local/lib/liblua.5.1.dylib \
    -compatibility_version 5.1 -current_version 5.1.2 \
    -o liblua.5.1.2.dylib *.o

gcc -fno-common -DLUA_USE_POSIX -DLUA_USE_DLOPEN -DLUA_USE_READLINE -lreadline -L. -llua.5.1.2 lua.c -o lua

That should be it. :)

Fink 'lua51' packaging has the necessary changes since 5.1.2-3.

  Usage on FreeBSD:

Unlike in Linux, also the Lua engine used with Lanes needs to be compiled with
'-lpthread'. Otherwise, the following malloc errors are received:

    lua in free(): warning: recursive call
    PANIC: unprotected error in call to Lua API (not enough memory)

Here are the Lua compilation steps that proved to work (FreeBSD 6.2 i386):

    gmake freebsd
    rm lua.o luac.o liblua.a
    gcc -shared -lm -Wl,-E -o *.o
    gcc -O2 -Wall -DLUA_USE_LINUX -lm -Wl,-E -lpthread -lreadline -L. -llua.5.1.2 lua.c -o lua

To compile Lanes, use 'gmake' or simply:

    cc -O2 -Wall -llua.5.1.2 -lpthread -shared -o out/bsd-x86/ \
        -DGLUA_LUA51 gluax.c lanes.c

To place Lua into ~/local, set the following environment variables (this is
just a reminder for myself...):

    export CPATH=.../local/include
    export LIBRARY_PATH=.../local/lib
    export LD_LIBRARY_PATH=.../local/lib

  Manual installation

After running GNU make, in directory `src` you will find files
`lanes.lua` and `lanes/`.  The first goes into a directory on
your LUA_PATH, and the `lanes` directory goes into a directory on your
LUA_CPATH.  If you are not sure how this works, try creating


  Note about LuaJIT
It looks like LuaJIT makes some assumptions about the usage of its allocator.
Namely, when a Lua state closes, memory allocated from its alloc function might be freed, even if said memory
isn't actually owned by the state (for example if the allocator was used explicitly after retrieving if with lua_getallocf)
Therefore it seems to be a bad idea, when creating a new lua_State, to propagate the allocator
from another state, as closing the first state would invalidate all the memory used by the second one...
The best is therefore to leave the 'allocator' configuration option unset when running LuaJIT.

You can’t perform that action at this time.