lualanes / lanes Goto Github PK
View Code? Open in Web Editor NEWLanes is a lightweight, native, lazy evaluating multithreading library for Lua 5.1 to 5.4.
License: Other
Lanes is a lightweight, native, lazy evaluating multithreading library for Lua 5.1 to 5.4.
License: Other
Documentation is available online at http://lualanes.github.io/lanes/ (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 (http://www.icir.org/gregor/tools/pthread-scheduling.html) describes fairly well, what (all) is wrong with Linux threading, even today. For other worthy links: http://kerneltrap.org/node/6080 http://en.wikipedia.org/wiki/Native_POSIX_Thread_Library 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 -> [email protected] 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 liblua.5.1.2.so *.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/lua51-lanes.so \ -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/core.so`. 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 /usr/local/share/lua/5.1/lanes.lua /usr/local/lib/lua/5.1/lanes/core.so ======================= 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. (end)
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...
cc -Wall -Werror -O2 -I/usr/include/lua5.1 -D_GNU_SOURCE -fPIC -c -o tools.o tools.c
tools.c: In function ‘lookup_native_func’:
tools.c:1224:3: error: field width specifier ‘*’ expects argument of type ‘int’, but argument 3 has type ‘size_t’ [-Werror=format]
cc1: all warnings being treated as errors
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:
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:
_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.__index
accessor doesn't use rawset()
to store the lane's return valuesIn 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
tools.c: In function ‘inter_copy_func’:
tools.c:1441: error: unused variable ‘cfunc’
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.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.