lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]


I think I have protected all stack manipulation as well but ... it's crashing.
I'll try to disable the Lua part processing message arrival to see if it's better or not ...



Le Jeudi 1 octobre 2015 16h04, Roberto Ierusalimschy <roberto@inf.puc-rio.br> a écrit :


> I'm working on a C application, https://github.com/destroyedlolo/Selene
>  , which is receiving some MQTT data. Those data are handled by a seperate thread.
> This application uses Lua scripts for customisation purposes, which can be launched from both the main thread, or the receiving one.
> As I know it is not possible to have shared access on Lua's context, I surrounded pcall()s by exclusive mutex ... but unfortunately, my application is crashing after a while and pcall return some corrupted lua code :
> *E* (ToDo) ./Selenite/Design.lua:20: attempt to call method '' (a nil value)
> *E* (ToDo) ./Selenite/Design.lua:20: attempt to call method '' (a nil value)
> *E* (ToDo) [string "./Selenite/Design.lua"]:40: attempt to call field '��' (a nil value)
> *E* (ToDo) ./Selenite/Design.lua:20: attempt to call method �0h�0' (a nil value)
> *E* (ToDo) ./Selenite/Design.lua:20: attempt to call method �0h�0' (a nil value)
>
> Is it safe to 2 different threads accessing the same Lua's context if they can't do it at the same time ?


If you access some data from two different threads using mutexes
properly, from the data point of view it is as if there is only
one thread accessing it, as all accesses are serialized. So that should
be safe. But remember that you have to protect all accesses to Lua,
not only 'pcall'. You have to protect pushing parameters and retrieving
results too, all in the same lock (otherwise another thread can
change the stack between that sequence).

-- Roberto