lualanes / lanes Goto Github PK

If I run the following program:

require("luarocks.loader")
require("lanes").configure()

I get this error:

lua: /usr/local/share/lua/5.1//lanes.lua:287: Recursive use of upvalues; cannot copy the function
stack traceback:
  [C]: in function 'thread_new'
  /usr/local/share/lua/5.1//lanes.lua:287: in function </usr/local/share/lua/5.1//lanes.lua:286>
  /usr/local/share/lua/5.1//lanes.lua:524: in function 'configure'
  test.lua:2: in main chunk
  [C]: ?

It works if I don't require luarocks.loader.

If I create a lane from inside a lane the first lane may finish without closing the second lane. It seems reasonable for me if this is what the programer wants, but if it happens because he forgets to exit the second lane It would be convenient to have a full list of all running lanes in order to be able to cancel them.

If this happens, when you close the main thread everything finishes, but when I did the same while degugging with msvc I got an exception: reading from bad location...

LuaJIT2 only accepts Lua code in source form, since its VM doesn't use the same opcodes as the regular one. The net result is that one can't use Lanes with LuaJIT2.

Two options to fix this:

• embed keeper.lua in text form
• reimplement the keeper logic in C

I would love to have more documentation for lanes:

As a lua programmer I still dont understand the difference between require"something" from inside a lane and creating the lane with opt_tbl={required={"something"}}.

As a C programmer I would like to have better understanding of which is the general mechanism of lua lanes: what are keepers, function transfer,source and destination database etc. Just reading the code is too difficult for me.

Best Regards
Victor Bombi

It seems that some of the tests have a problem closing out when Lua is tearing itself down.

32-bit machine uname -a: Linux pinetrail 3.0.0-13-generic #22-Ubuntu SMP Wed Nov 2 13:25:36 UTC 2011 i686 i686 i386 GNU/Linux
64-bit machine uname -a: Linux ionic 3.0.0-13-generic #22-Ubuntu SMP Wed Nov 2 13:27:26 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux

I have tried GDB on a 32-bit and 64-bit machine and it complains that it cannot track the threads.

Starting program: /usr/bin/lua5.1 tests/errhangtest.lua
[Thread debugging using libthread_db enabled]
Cannot find new threads: generic error

It seems that each of the tests have a chance of this hang. If you know any trick for managing this generic error, let me know.

Encountered at revision: v3.0-beta-10-g60a0e70 60a0e70

When doing

lanes.timer( linda, "miditimer", 0 )

to stop the timer

an assert in LanesTimer exits the lane without being noticed.

I would suggest this new gen function which show errors in LanesTimer and allows sendin period==nil for stoping the timer. (Negative periods are accounted in set_timer):

gen( "", { priority=max_prio}, function() -- "" instead of "io,package" for LuaJIT compatibility...
set_debug_threadname( "LanesTimer")
set_finalizer(function (err,stk)
if err and type(err)~="userdata" then
WR( "LanesTimer error: "..tostring(err) )
elseif type(err)=="userdata" then
WR( "LanesTimer after cancel" )
else
WR("LanesTimer finalized")
end
end)
while true do
local next_wakeup= check_timers()

        -- Sleep until next timer to wake up, or a set/clear command
        --
        local secs
        if next_wakeup then
            secs =  next_wakeup - now_secs()
            if secs < 0 then secs = 0 end
        end

        local linda= timer_gateway:receive( secs, TGW_KEY )

        if linda then
            local key= timer_gateway:receive( 0.0, TGW_KEY )
            local wakeup_at= timer_gateway:receive( 0.0, TGW_KEY )
            local period= timer_gateway:receive( 0.0, TGW_KEY )

            set_timer( linda, key, wakeup_at, period )
        elseif secs == nil then -- got no value while block-waiting?
            WR( "timer lane: no linda, aborted?")
        end
    end
end )()

In my understanding of the functions that THREAD_KILL binds to ( pthread_cancel and TerminateThread ), they leave all objects/memory accessed by that thread in an undetermined state. But Lanes' cleanup function attempts to run lua_close() on a Lua state managed by a killed thread. This is why the "pthread_cond_destroy(ref) failed, 16 EBUSY" error message was followed by a crash, since the Lua state it was trying to cleanup was left in an undetermined state when it was killed.

A similar situation is in thread_gc, but in this case, this case the lua_close() is commented out with a note about the safety of closing a killed state.

In any case, running lua_close() on a state that has been killed will cause problems and the only fix I know of is to just not do it. Are the other better solutions?

Lanes needs LUA_COMPAT_ALL not defined for Lua 5.2 but there are still alot of modules: wxLua, luasocket, etc that need the oposite. Beasides that LUA_COMPAT_ALL is the default option in the Lua makefile. For that reason is not possible for me to make the jump to Lua 5.2.
Is there any chance to change this situation?

Best
victor

I am using

package.loaded["lua51-lanes"].now_secs()

for getting time with ms precision as os.time() just gives seconds.
I think it would be meaningfull to include it in the lanes exposed api

Best Regards

Victor Bombi

Excuse me. I dont know where to ask so i am posting here
I get this error and i dont know what it means:
C:\LUA\luabin5.1.5\lua.exe: C:\LUA\luabin5.1.5\lua\lanes.lua:249: function not found in origin transfer database.
stack traceback:
[C]: in function 'thread_new'
C:\LUA\luabin5.1.5\lua\lanes.lua:249: in function 'midi_lane_gen2'
C:\LUA\luabin5.1.5\lua\victor\testluapmidi.lua:196: in main chunk
[C]: ?
the function is generated as:
midi_lane_gen2=lanes.gen("*",
{
required={"pmidi"},
globals={dump=prtable,linda=linda,lanes=lanes},
priority=0},
pmidi.midi_thread)
pmidi is a lua port of portmidi library made by me
Error does not happen if the function in pmidi.midi_thread is outside the module.
globals={pmidi=pmidi} gives the same error

Hello,

I get this building with mingw

C:\LUA\lanessource\repo\lanes\src\lanes.c: In function 'LG_configure':
C:\LUA\lanessource\repo\lanes\src\lanes.c:2821:4: error: too many arguments to function 'init_once_LOCKED'
init_once_LOCKED( L, on_state_create, nbKeepers, shutdown_timeout, track_lanes, protect_allocator);
^
C:\LUA\lanessource\repo\lanes\src\lanes.c:2614:13: note: declared here
static void init_once_LOCKED( lua_State* L, int const _on_state_create, int const nbKeepers, lua_Number _shutdown_timeout, b
ool_t _track_lanes)

Best
victor

I am using lanes wit the latest code in git repo, but when I load my own lua module with:

local zax = lanes.require "zax"

error occurred:

e:\sample.wlua:101: error requiring 'zax' in keeper state: module 'zax' not found:

I am using embedded lua, which means all modules are statically linked (no dll). I am sure 'zax' module was loaded because I can use it. The error only occurred when using 'lanes.require'

I'm having difficulty using LuaLanes (v.3.1.0 tag) with LuaJIT 2.0.0-beta9 on an ARM platform. LuaJIT runs fine but if I have a simple program that does the following:

local lanes = require "lanes"
lanes.configure()

I get the following error:

function package.preload.ffi not found in destination transfer database.

This seems like it may be related to the issue reported here:

http://lua-users.org/lists/lua-l/2011-11/msg00554.html

I know LuaJIT has a couple of "builtin" modules, notably the 'ffi' module for foreign function interface support. I assume this is being loaded by the LuaJIT VM before the above code has a chance to execute. Reading later postings it seems that some people have been able to use LuaLanes with LuaJIT2. Can anyone verify that LuaLanes indeed works with LuaJIT2? Can someone explain to me why I'm getting the above error and if there is any work-around that I can apply?

Thanks . . .

If I use lane:cancel(0.1,true) I get an assertion from lanes.c on 2079 that prints :Status: 1

May be I dont understand the mechanism but it was neccessary to rename by hand lua51-lanes.dll to core.dll and put it inside c_path/lanes/ and there was a complain about keeper.lua not found (by bin2c) which is now replaced by lanes-kepper.lua in the lua path

this happens with CMakeLists.txt and make-vc.cmd.
I dont use rockspec so I dont know if it works

minor issue:

lanes.cancel_error is not pushed from lanes51-lanes to lanes by lanes.lua

PD: Thank you. Lanes is being so useful to me in developing a multithread realtime application with wxlua interface, midi acces, udp comunication (OSC to supercollider) and script execution

I have a commit over in my repo that you could merge into a gh-pages branch. See: http://cmr.github.com/lanes/.

Not necessary, but it's quite useful IMO.

The provided Makefile fails to build on 64-bit Linux (Ubuntu 12.04LTS) due to the fact that it's built with -Werror and a warning in a format specifier causes it to fail. Specifically, in the file lanes.c on lines:

line: 716
line: 743
line: 754

The sizeof() operator on x86_64 appears to return an unsigned long integer but the '%.*s" format specifier expects an integer. For example, line 716

Before:
len = sprintf( text, "linda: %.*s", sizeof(text) - 8, linda->name);

After Fix:

len = sprintf( text, "linda: %.*s", (int)(sizeof(text) - 8), linda->name);

The sizeof() needs to be cast to an integer to remove the warning.

Without having tested it --- the assertion, that Lua Lanes on Linux is second class because of broken threading assumptions dates back to Ubuntu 7.04. This system is now 6 years old, unmaintained by Canonical and was using Linux kernel 2.6.20.

The Readme would deserve a re-assertion of this statement or at least a caveat.

When calling a generator created with lanes.gen(), we get a proxy, which is a regular Lua table.
This table has several issues:

• it contains 3 fields, _ud, join and cancel, which are totally unprotected against overwrite by the user. Similarly, once it is populated with the lane's return values (indexed with numeric keys), theses values aren't protected against overwrite.
• its metatable is accessible from user code
• the metatable __index accessor doesn't use rawset() to store the lane's return values

In a sense, leaving write access to the return values is understandable. But _ud, join and cancel must be protected against overwrite, and the metatable shouldn't be accessible.

Edit: a way to solve these issues is to hide the storage table containing _ud, join and cancel, and receiving the lane's return values, as a full userdata's environment table. One drawback I see is that one can no longer iterate over the indices to extract the return values. Of course, this can be solved by adding an iterator to the proxy's interface.

My program with lualanes and wx had been always working. When I recompiled with mingw I got wx hang and crash when my lane was finished. I did try alot of things but nothing seemed to work. Finally I realized that:

If I require"something" inside a lane that has not been required in the lua_state
where wx is loaded("main" one). When the lane is finished wx gets hanged (I guess that
when unloading the dll) so I am now requiring everything in the main
lua_state even if I dont need it.
Another problem came from wx defining bit instead of wx.bit so when I use bit from luaBitOp lanes get confused. (I renamed it bitOp for solving) but I suposse that this is by design and not a bug.

Best Regards
Victor Bombi

Here's a simple program which spawns 2 threads using Lanes, and they do ping/pong for 100 times using Linda. But the program just hang there and no message can be passed through Linda:

local lanes = require 'lanes'.configure()
local q = lanes.linda()

local pingpong = function(name, qr, qs, start)
    print("start " .. name)
    local count = 0
    if start then
        print(name .. ": sending " .. qs .. " 0")
        q:send(qs, 0)
    end
    while count < 100 do
        print(name .. ": receiving " .. qr)
        local key, val = q:receive(qr)
        if val == nil then
            print(name .. ": timeout")
            break
        end
        print(name .. ":" .. val)
        val = val + 1
        print(name .. ": sending " .. qs .. " " .. tostring(val + 1))
        q:send(qs, val)
        count = count + 1
    end
end

local t1, err1 = lanes.gen("", pingpong)("L1", '0', '1', true)
local t2, err2 = lanes.gen("", pingpong)("L2", '1', '0', false)

t1:join()
t2:join()

The output is:

start L1
L1: sending 1 0
start L2
L2: receiving 1

and just hangs there...

Sending nothing to a linda by forgetting to provide some values after the key does nothing. It is therefore a no-op that should probably raise an error because it is most probably not intended.

The id_func for deep userdata objects appears to be a normal lua_CFunction type function, but yet it is not copied or accessed properly if various places of the deep userdata system.

If the id_func depends on upvalues or on Lua's automatic stack cleanup, it would not work with the deep userdata system, since it takes a pointer to the function from L and then pushes a new closure onto L2 without copying upvalues. Also luaG_deep_userdata ( other places too? ) it just calls the id_func directly through the function pointer, rather than calling through the closure with lua_call.

It's not that hard to write your id_func to not rely on closures, module initialization and automatic stack cleanup, so simply mentioning these limitations in the documentation could be all that is needed to address this issue right now.

It appears to be caused by the mutexes used by keeper_acquire not getting released during/after the call to luaL_error(), which causes the whole Lua state to hang when the Linda id_func is called to delete the linda deep UD object ( since it uses keeper_acquire itself ).

The following code demonstrates this issue:
require('lanes').linda():send('test', coroutine.create(function() end))

Fortunately, the only time this shows up is when there was already going to be an error, so the only inconvenience it causes is that the program hangs instead of shutting down and there is no visible error message, leaving the user with very little clue of what went wrong.

OS:: Windows 7 Ultimate 64bit
Compiler : VC10 32bit (vcvars32.bat)
Installation command : luarocks install https://github.com/LuaLanes/lanes/raw/master/lanes-3.1.5-1.rockspec

Other environment information: cygwin in path, using lua 5.1.4 from luarocks

I've tried about 100 things to get this to work but it just won't load core.dll without crashing. I've also tried using older versions of the library, and different versions of lua. Same issue every time. I know it's something to do with my environment, but other modules like luafilesystem work fine when built from source on my system using msvc. Any ideas?

Why do I get:

testlaneswx.lua:23: attempt to index global 'wx' (a nil value)

when I run

local lanes=require("lanes")
lanes.configure()
local linda= lanes.linda()

oldprint=print
require("wx")
print=oldprint

function wx_thread()
    set_finalizer(function (err,stk)
                if err  and type(err)~="userdata" then 
                    print( "wx_thread error: "..tostring(err) )
                elseif type(err)=="userdata" then 
                    print( "wx_thread after cancel" )
                else
                    print("wx_thread finalized")
                end 
            end)
    oldprint=print
    require("wx")
    print=oldprint

    frame = wx.wxFrame( wx.NULL, wx.wxID_ANY, "wxLua Very Minimal Demo2",
                        wx.wxDefaultPosition, wx.wxSize(450, 450),
                        wx.wxDEFAULT_FRAME_STYLE )
    frame:Show(true)
    wx.wxGetApp():MainLoop()
    return true
end
wx_threadlane=lanes.gen("*",wx_thread)()

frame = wx.wxFrame( wx.NULL, wx.wxID_ANY, "wxLua Very Minimal Demo1",
                        wx.wxDefaultPosition, wx.wxSize(550, 550),
                        wx.wxDEFAULT_FRAME_STYLE )
frame:Show(true)

wx.wxGetApp():MainLoop()

Despite the comments in threading.c, condition variable emulation based on PulseEvent() is really not working for newer Windows systems. Any lua code using higher level of linda communication will hang soon enough. Following sample lua fragment usually hangs in several seconds on Win7 due to lost wakeup inside SIGNAL_WAIT():

local function RunnerThread(hPinda, nId, bPong)
    local sPingKey = "Ping_".. nId
    local sPongKey = "Pong_".. nId
    local sStatKey = "Stat_".. nId

    local nCnt = 0
    while true do
        if bPong then
            nCnt = hPinda:receive(nil, sPingKey) 
            hPinda:send(sPongKey, nCnt + 1)
        else
            hPinda:send(sPingKey, nCnt + 1)
            nCnt = hPinda:receive(nil, sPongKey)

            if nCnt % 1000 < 2 then
                hPinda:send(sStatKey, nCnt)
            end 
        end
    end
end

local hJenda = lanes.linda()
local gFnc = lanes.gen(nil, RunnerThread)
local sStatKey = "Stat_1"

gFnc(hJenda, 1, false)
gFnc(hJenda, 1, true)

while true do
    local val, key = hJenda:receive(10, sStatKey)
    if val then
        print(key, val)
    end
end

I have got this message in my SClua application:

timer lane: no linda, aborted?
and it is not aborted because I can use linda

reading lanes.lua i see::

444 local linda= timer_gateway:receive( secs, TGW_KEY )
...
...
453 elseif secs == 0 then -- got no value while block-waiting?
WR( "timer lane: no linda, aborted?")

but receive with timeout==0 is not block-waiting. Is that correct?

I don't know if the difficulty lies in the software, the documentation, or the install instructions. I built Lanes without difficulty, but then when I placed the lanes directory on my LUA_CPATH, attempts to load it failed:

: nr@homedog 10210 ; lua
Lua 5.1.4  Copyright (C) 1994-2008 Lua.org, PUC-Rio
> require 'lanes'
error loading module 'lanes' from file '/home/nr/machine/i686-linux/lib/lua5.1/lanes/core.so':
        /home/nr/machine/i686-linux/lib/lua5.1/lanes/core.so: undefined symbol: luaopen_lanes
stack traceback:
        [C]: ?
        [C]: in function 'require'
        stdin:1: in main chunk
        [C]: ?
> 

Environment : win32
compiler : vc++ 10
lua version : luarocks embedded 5.1.4
test case ::

lanes = require 'lanes'.configure()

f = lanes.gen(function(a)
return a
end)

res = f(1)

print(res[1]) --prints 1

g = lanes.gen(function(a)
print(a)
end)

res = g(1)
print(res[1]) -- stack dump

I have problems trying to cancel a lane. It says it is cancelled but obviously not because it dumps output.
I am trying to reproduce the behaviour in a short example but a cant. In the meanwhile a found a strange behaviour: it happens with cancelstep different from 100 or without cancelstep.

local lanes=require("lanes")
lanes.configure({ nb_keepers = 1, with_timers = true, on_state_create = nil})
local linda= lanes.linda()


local function loop()
    set_finalizer(function(err) 
        print("finalizer",err)
    end)
    local i=0
    while true do       
        print("loop",i)
        i=i+1
    end
end

looping_lane=lanes.gen("*",{cancelstep=1000},loop)()
--looping_lane=lanes.gen("*",loop)()

linda:receive( 1, "dummy") -- let some time 
testcancel=looping_lane:cancel(0.1,true)
print("testcancel ",testcancel)
print("starus ",looping_lane.status)
linda:receive( 3, "dummy")
print("end")

This is the first time I'm trying LuaLanes out since I'm looking for some preemptive threading support for Lua.

I built LuaLanes from trunk using MSYS + Mingw32 gcc 4.6.3 compiler (mingw-w64.sourceforge.net). I did two different builds here, one that links against LuaJIT 2.0.1 and another linking to Lua-5.1.5.

They both build ok but when I do a 'make test' the LuaJIT build crashes after running one script. In fact, running any of the tests results in a crash eg. make fifo crashes. The other build linking against vanilla Lua works just fine however, no crashes on that one.

Before this, I also tested it linking against LuaJIT 2.0.0 Beta8 and that exhibits the same crashing problem.

Naturally, the next thing I did was run it through gdb and see what the callstack looks like. Command used to do this:

gdb --args luajit ../tests/fifo.lua

Followed with a run I get:

Output from fifo.lua:

Sending to A..
Sending to B..
Reading A..
FIFO3   1
Reading B..
FIFO4   a

Output from gdb up to where fifo crashed:

$ gdb --args luajit ../tests/fifo.lua
GNU gdb (GDB) 7.5.50.20120804-cvs
Copyright (C) 2012 Free Software Foundation, Inc.
...
Reading symbols from g:\LuaJIT-2.0.1\luajit.exe...(no debugging symbols found)..
.done.
(gdb) run
Starting program: g:\LuaJIT-2.0.1\luajit.exe ../tests/fifo.lua
[New Thread 6940.0x1a24]
[New Thread 6940.0x5e0]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 6940.0x5e0]
0x66dc2247 in ?? () from g:\LuaJIT-2.0.1\lua51.dll
(gdb) bt
#0  0x66dc2247 in ?? () from g:\LuaJIT-2.0.1\lua51.dll
#1  0x66d86f39 in ?? () from g:\LuaJIT-2.0.1\lua51.dll
#2  0x66d84c2b in ?? () from g:\LuaJIT-2.0.1\lua51.dll
#3  0x66d85738 in ?? () from g:\LuaJIT-2.0.1\lua51.dll
#4  0x66d8ae9c in ?? () from g:\LuaJIT-2.0.1\lua51.dll
#5  0x70d85d85 in lane_main@4 () from g:\OSS\LuaLanes\src\lanes\core.dll
#6  0x74dd1287 in msvcrt!_itow_s () from C:\Windows\syswow64\msvcrt.dll
#7  0x74dd1328 in msvcrt!_endthreadex () from C:\Windows\syswow64\msvcrt.dll
#8  0x76b3339a in KERNEL32!BaseCleanupAppcompatCacheSupport ()
   from C:\Windows\syswow64\kernel32.dll
#9  0x00371250 in ?? ()
#10 0x771f9ef2 in ntdll!RtlpNtSetValueKey ()
   from C:\Windows\system32\ntdll.dll
#11 0x00371250 in ?? ()
#12 0x771f9ec5 in ntdll!RtlpNtSetValueKey ()
   from C:\Windows\system32\ntdll.dll
#13 0x74dd12e5 in msvcrt!_endthreadex () from C:\Windows\syswow64\msvcrt.dll
#14 0x00000000 in ?? ()

I'm stumped at this point. Any idea what could cause this to segfault and crash when using LuaJIT but not with vanilla Lua?

Just to be sure it wasn't a toolchain issue, I rebuilt everything using the same compiler and linker version.

running tests/require.lua prints:

function 'package/preload/ffi' not found in Lane #0x004a8380 destination transfer database.

instead of

LUAG_FUNC( thread_cancel)
{
if( lua_gettop( L) =! 1 || lua_type( L, 1) != LUA_TUSERDATA)

perhaps you mean

LUAG_FUNC( thread_cancel)
{
if( lua_gettop( L) < 1 || lua_type( L, 1) != LUA_TUSERDATA)

By the way I made a modification for getting errors with complete source,currentline,what,name and namewhat in order to show the line and source in a editor in case of error:

STACK_GROW(L,4);
...
...
while( lua_getstack(L, ++lev, &ar ) ) {
lua_getinfo(L, "Sln", &ar);
/*
if (ar.currentline > 0) {
lua_pushinteger( L, n++ );
lua_pushfstring( L, "%s:%d", ar.short_src, ar.currentline );
lua_settable( L, -3 );
*/

        lua_newtable(L);

        lua_pushstring(L,"source");
        lua_pushstring(L,ar.source);
        lua_settable( L, -3 );

        lua_pushstring(L,"currentline");
        lua_pushinteger(L,ar.currentline);
        lua_settable( L, -3 );

        lua_pushstring(L,"name");
        lua_pushstring(L,ar.name);
        lua_settable( L, -3 );

        lua_pushstring(L,"namewhat");
        lua_pushstring(L,ar.namewhat);
        lua_settable( L, -3 );

        lua_pushstring(L,"what");
        lua_pushstring(L,ar.what);
        lua_settable( L, -3 );

        lua_rawseti(L,-2,n++);


   // }
}

Hello Benoit

"Sometimes" the thread that is running the lanes.timer (That one with high priority) gets all the cpu time from the core in which it is running may be during a second in a very erratic way. The funny thing is that all timers are supposed to be stoped. If then I start one timer cpu goes to 25% but all the time.

I cant reproduce it in a small program. It only happens in my "complex" program ( windows and mingw are used ) and I dont know how to investigate it.

Any suggestions?

Best
Victor Bombi

Recent versions (latest git included) give this error when trying to require "lanes":

lua: error loading module 'lanes.core' from file '/home/hinrik/.luarocks/lib/lua/5.1/lanes/core.so':
    /home/hinrik/.luarocks/lib/lua/5.1/lanes/core.so: undefined symbol: pthread_mutexattr_settype
stack traceback:
    [C]: ?
    [C]: in function 'require'
    /home/hinrik/.luarocks/share/lua/5.1/lanes.lua:58: in function 'configure'
    lan-test.lua:1: in main chunk
    [C]: ?

With version 3.1.5, the build type was changed from "make" to "builtin". This causes LuaRocks to ignore the Makefile in the distribution, and consequently fail to use necessary flags such as -lpthread on Linux. lanes-3.1.4.rockspec (see 37b0d64) is the last one to build correctly (though luarocks does complain about the missing revision at the end of its version number).

Note the lack of -lpthread:

$ luarocks --local install lanes
Installing http://luarocks.org/repositories/rocks/lanes-3.1.6-1.src.rock...
Using http://luarocks.org/repositories/rocks/lanes-3.1.6-1.src.rock... switching to 'build' mode
Archive:  /tmp/luarocks_luarocks-rock-lanes-3.1.6-1-1273/lanes-3.1.6-1.src.rock
  inflating: lanes-3.1.6-1.rockspec  
   creating: lanes/
  inflating: lanes/CMakeLists.txt    
  inflating: lanes/README            
  inflating: lanes/make-vc.cmd       
  inflating: lanes/setup-vc.cmd      
  inflating: lanes/dist.info         
  inflating: lanes/COPYRIGHT         
  inflating: lanes/CHANGES           
  inflating: lanes/BUGS              
  inflating: lanes/lanes-3.1.5-1.rockspec  
  inflating: lanes/lanes-3.1.6-1.rockspec  
  inflating: lanes/ABOUT             
   creating: lanes/tests/
  inflating: lanes/tests/appendud.lua  
  inflating: lanes/tests/fibonacci.lua  
  inflating: lanes/tests/irayo_closure.lua  
  inflating: lanes/tests/objects.lua  
  inflating: lanes/tests/error.lua   
  inflating: lanes/tests/errhangtest.lua  
  inflating: lanes/tests/argtable.lua  
  inflating: lanes/tests/assert.lua  
  inflating: lanes/tests/recursive.lua  
  inflating: lanes/tests/fifo.lua    
  inflating: lanes/tests/hangtest.lua  
  inflating: lanes/tests/cyclic.lua  
  inflating: lanes/tests/require.lua  
  inflating: lanes/tests/atomic.lua  
  inflating: lanes/tests/func_is_string.lua  
  inflating: lanes/tests/linda_perf.lua  
  inflating: lanes/tests/perftest.lua  
  inflating: lanes/tests/atexit.lua  
  inflating: lanes/tests/ehynes.lua  
  inflating: lanes/tests/irayo_recursive.lua  
  inflating: lanes/tests/protectproxy.lua  
  inflating: lanes/tests/finalizer.lua  
  inflating: lanes/tests/timer.lua   
  inflating: lanes/tests/launchtest.lua  
  inflating: lanes/tests/basic.lua   
  inflating: lanes/tests/keeper.lua  
   creating: lanes/docs/
  inflating: lanes/docs/index.html   
  inflating: lanes/docs/multi.png    
  inflating: lanes/docs/Lua multithreading choices.svg  
 extracting: lanes/docs/Lua multithreading choices.graffle  
  inflating: lanes/docs/comparison.html  
  inflating: lanes/docs/performance.ods  
  inflating: lanes/dist.cmake        
  inflating: lanes/Makefile          
  inflating: lanes/TODO              
   creating: lanes/src/
  inflating: lanes/src/keeper.h      
  inflating: lanes/src/tools.c       
  inflating: lanes/src/lanes.c       
  inflating: lanes/src/keeper.c      
  inflating: lanes/src/lanes-keeper.lua  
  inflating: lanes/src/lanes.lua     
  inflating: lanes/src/tools.h       
  inflating: lanes/src/threading.c   
  inflating: lanes/src/threading.h   
  inflating: lanes/src/Makefile      
gcc -O2 -fPIC -I/usr/include/lua5.1 -c src/lanes.c -o src/lanes.o -Isrc
gcc -O2 -fPIC -I/usr/include/lua5.1 -c src/keeper.c -o src/keeper.o -Isrc
gcc -O2 -fPIC -I/usr/include/lua5.1 -c src/tools.c -o src/tools.o -Isrc
gcc -O2 -fPIC -I/usr/include/lua5.1 -c src/threading.c -o src/threading.o -Isrc
gcc -shared -o lanes/core.so -L/usr/local/lib src/lanes.o src/keeper.o src/tools.o src/threading.o
Updating manifest for /home/hinrik/.luarocks/lib/luarocks/rocks

lanes 3.1.6-1 is now built and installed in /home/hinrik/.luarocks/ (license: MIT/X11)

I get the following message at the end of any Lua script with LuaJIT2 (not always but most of the time):

This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.
ReleaseMutex() failed! (6)

Sometimes the message is WaitForSingleObject() failed! (6)

luajit is from http://luajit.org/git/luajit-2.0.git (compiled on July 04 with mingw)
OS is 32bit winxp sp3

I use custom loader that finds lua modules.
I set LUA_INIT=@path/to/loader.lua.
When i call thread_new i get "error requiring 'lanes.core' in keeper state: module 'lanes.core' not found"
How i can load my loder before lanes try load any non standart modules.

PS. there error in doc: doc - on_create_state. lanes.lua - on_state_create.

Build fails in Lua 5.2:
src/lanes.c:1672: error: ‘LUA_GLOBALSINDEX’ undeclared (first use in this function)

Quick-cocos2d-x is a good game develop framework with lua. I want to embed lanes into quick-cocos2d-x like lua-socket ( https://github.com/dualface/quick-cocos2d-x/tree/master/lib/lua_extensions ). but It is too difficult for me.

Could you give me some advices?

I got this a assertion running lanes 3.1.5 after trying to kill with script_lane:cancel(0.1,true) a lane in which probably an udp socket is blocked in a receive() operation

script_lane:cancel(0.1,true)== false althought script_lane.status=="cancelled" (Is this possible?)

then with lane:join() the assertion is generated and Status: 1 printed.

I also was commented in a previous issue for which I provided an example. In this new example I call join() which shows the assertion. In the "big" program I call join because status says cancelled.

New example

local lanes=require("lanes")
lanes.configure({ nb_keepers = 1, with_timers = true, on_state_create = nil})
local linda= lanes.linda()

require("socket")

local function receive()
    set_finalizer(function(err) 
        print("finalizer",err)
    end)
    require("socket")
    listenudp = socket.udp()
    listenudp:setsockname("127.0.0.1", 57220)
    while true do       
        print("waiting")
        local dgram,status = listenudp:receive()
        print(dgram,status)
    end
    listenudp:close()
end


udp1 = socket.udp()
udp1:setpeername("127.0.0.1", 57220)

receiving_lane=lanes.gen("*",receive)()
linda:receive( 1, "dummy") -- let some time to prepare receive

print("sending")
udp1:send("message")
iscancelled=receiving_lane:cancel(0.1,true)
print("iscancelled ",iscancelled," receiving_lane.status ",receiving_lane.status )
print(receiving_lane:join())
linda:receive( 3, "dummy")

udp1:close()

I'm using Lanes 3.1.3 and my programs sometimes hang even when lanes are done. Here is a test case:

async = function()
    print("foo")
end

local lanes = require "lanes"
lanes.configure()

local f = lanes.gen("*", async)
local a = f()
local b = f()
a:join()
b:join()
print(a.status)
print(b.status)

This will print the following output:

foo
foo
done
done

However, it will sometimes just hang afterwards (with the same output), instead of exiting. I've experienced this with both LuaJIT 2.0.0 beta9 and Lua 5.1.5 (where it happens slightly more often). I'm using Linux 3.2.0 on Debian testing.

After a bit of poking around in the debugger, I still wasn't able to find a good reason for this seg fault, so I'm opening a new issue for it rather than hijacking the other issue.

a661736 introduces something that causes Lua to seg fault on exit on my system.

To reproduce this, I just run
require('lanes')

In all cases, using all of the tools I have available, the seg fault only appears during the Lua userdata GC methods for the timer thread after the lua51-lanes.so library is unloaded. So somehow, it appears like the lanes library is getting unloaded, even though it used to always stay loaded and this library unloading before GC metamethod issue only affected non-lanes libraries.

I'm running out of ideas on how I can track down this bug, so any suggestions would be appreciated. The only other method left that I can think of would be to incrementally add the changes introduced in a661736 and try to see which change causes the seg fault and then figure out what that change is doing wrong.

One may want to add custom loaders, which isn't possible at the time.

Howdy,

Small issue with lanes.genlock.

> linda = lanes.linda()
> linda:limit('a', 1)
> linda:set('a', 22)
> t=os.time() linda:send(3, 'a', 66) print(os.time()-t)
0
> t=os.time() linda:send(3, 'a', 66) print(os.time()-t)
0
> t=os.time() linda:send(3, 'a', 66) print(os.time()-t)
0

> linda = lanes.linda()
> linda:limit('a', 1)
> --linda:set('a', 22)
> t=os.time() linda:send(3, 'a', 66) print(os.time()-t)
0
> t=os.time() linda:send(3, 'a', 66) print(os.time()-t)
3
> t=os.time() linda:send(3, 'a', 66) print(os.time()-t)
3

It seems that linda:set clears the limit for that key, solanes.genlock needs to call limit after set.
Not a particularly major issue, but it does make the function a little useless!

(P.S: LuaLanes is incredibly useful. Thank you so much for the time and effort you've invested into it!)

Problem is that the make-vc.cmd script relies on the detection of the lua51 executable. I have a situation where the detection fails.

Now, it happens that this file exists, and the rockspec uses it, because we used to embed keepers.lua in the lanes C code in (platform-dependant) bytecode format. Since we embed it in text form, the embedded header is now platform-independant, therefore we no longer need to generate it a build time.

This might mean the rockspec could be modified to use luarock's "module" building facility, thus elimitating the need to use this build script or to invoke the makefile. But I have to investigate to confirm this.