Hi Sean,
Thanks for your explanation and your code :)
But the think I'm missing is ... why I need to serialize function ?
I mean I know that function are variables like others and I'm propagating them form one thread to another :
1/ or by pushing the function itself as in Detach() : xmove to the main state to the slave one ...
In this case, code launched in the slave thread CAN access to global stuffs (with all the risks it's implying).
2/ or by retrieving first the function content from Lua's registry (https://www.lua.org/pil/27.3.1.html) and then pushing it using again xmove.
In this case, slave code CAN'T access to globals.
The only thing that is not working in both cases is metatable as we are discussing.
It seems from our discuss I'm cheating a bit here but I didn't get the limitation "can move from the same GLOBAL STATE". Simply ... why ? The only danger I can imagine is usage counters are squeezed and objects are subject to be collected. It is definitively not the case here as I'm dealing with constant code : it is stored "somewhere" in Lua's memory and stay until process death as not attached to any dynamic object.
Le Samedi 1 juillet 2017 4h49, Sean Conner <sean@conman.org> a écrit :
> So I played around with this today, and I created a github repository for
> those interested:
> https://github.com/spc476/LuaFunctionSerialize
I had a look and will deeply study it but ... the processing is made at Lua's side (which mean to me it will impact my application user scripts).
Anyway, I found a workaround by exposing method FIFO:Push() as a function, FIFO.PushFIFO() and it's working.
I'm currently running intensive testing to check there is no side effects or instability.
Rgds,
Laurent
