+- Cuberite Forum (https://forum.cuberite.org)
+-- Forum: Plugins (https://forum.cuberite.org/forum-1.html)
+--- Forum: Plugin Discussion (https://forum.cuberite.org/forum-8.html)
+--- Thread: Asynchronous tasks (/thread-1830.html)
RE: Asynchronous tasks - NiLSPACE - 04-15-2015
But as far as I know you can't send things like tables across lua states.
RE: Asynchronous tasks - worktycho - 04-15-2015
You can't easily transfer them, but a deep copy would not be too difficult. You wouldn't want to send big tables across but thats not the point of the web worker interface.
RE: Asynchronous tasks - xoft - 04-15-2015
A deep copy doesn't solve all the issues. Lua tables can have loops in them (such as in the default, _G._G == _G), so a naive deep copy operation will create an infinite loop.
RE: Asynchronous tasks - worktycho - 04-15-2015
A naive deep copy would have problems but a serialisation copy (serialise then deserialise) would not. As would a copy algorithm implemented sensibly. Or we could take the easy option and do what the Call function does and ban tables.
RE: Asynchronous tasks - NiLSPACE - 04-15-2015
I don't think it's a good idea to ban tables completely, because a class in Lua is a table. That would mean we wouldn't be able to give those classes to a different thread.
RE: Asynchronous tasks - worktycho - 04-15-2015
Do you mean the classes exposed by the api? I wasn't talking about those because at an bindings level their different and much simpler.
RE: Asynchronous tasks - NiLSPACE - 04-15-2015
No I mean classes like these: https://github.com/mc-server/WorldEdit/blob/master/CraftScripts.lua
RE: Asynchronous tasks - worktycho - 04-15-2015
So we'ed need to implement a non-naive deep copy function.
RE: Asynchronous tasks - NiLSPACE - 04-15-2015
Wouldn't it be slow to copy all the values over and over?
What is the big advantage if we give each thread it's own LuaState?
RE: Asynchronous tasks - worktycho - 04-15-2015
(04-15-2015, 09:24 PM)NiLSPACE Wrote: Wouldn't it be slow to copy all the values over and over?It depends what you're sending. I wouldn't recommend sending big Lua data structures over but for small things its fine.
(04-15-2015, 09:24 PM)NiLSPACE Wrote: What is the big advantage if we give each thread it's own LuaState?
It simplifies a lot of the multithreading issues. LuaStates are currently not thread safe but rely on each plugin only being called by one thread at a time. This makes having a worker thread for a plugin within the same state useless because you can't use it for long work due to blocking the plugin lock.
If we give the thread its own LuaState it means that we can use a separate lock for the thread rather than having to make LuaState thread safe.
Also it deals with issues like race conditions in plugin code. With the message passing API it is much harder the write race conditions into simple code.