Asynchronous tasks
#11
But as far as I know you can't send things like tables across lua states.
Reply
Thanks given by:
#12
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.
Reply
Thanks given by:
#13
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.
Reply
Thanks given by:
#14
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.
Reply
Thanks given by:
#15
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.
Reply
Thanks given by:
#16
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.
Reply
Thanks given by:
#17
No I mean classes like these: https://github.com/mc-server/WorldEdit/b...cripts.lua
Reply
Thanks given by:
#18
So we'ed need to implement a non-naive deep copy function.
Reply
Thanks given by:
#19
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?
Reply
Thanks given by:
#20
(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.
Reply
Thanks given by:




Users browsing this thread: 1 Guest(s)