+- 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 - xoft - 04-15-2015
Separate Lua States have similar shortcoming in the API department - it's not completely investigated whether the ForEachXYZ callback functions will keep their current semantics; all the callbacks will need their locks revised etc.
RE: Asynchronous tasks - worktycho - 04-15-2015
I don't think that ForEachXYZ can be rewritten due to the mutation issues. But that is a disscusion for another thread. So I don't think this should be blocked by that.
RE: Asynchronous tasks - NiLSPACE - 09-28-2015
I think the threading model could probably look best like this:
Main thread collects all needed information -> Creates new thread to process it -> Calls a function in the main thread to do something with the processed information.
In WorldEdit it could look like this:
User uses "//set stone,dirt" ->
The selected area is read into a cBlockArea ->
A new thread is created with a function that fills the cBlockArea with stone and dirt ->
The thread calls a function in the main thread with the cBlockArea as a parameter ->
The main thread writes the cBlockArea back in the world.
The only thing that could block the server with this is the reading and writing of the cBlockArea, but I doubt that could be fixed easily.
Long story short, perhaps threads created by a plugin shouldn't interact with worlds, entities, players etc. Just process information that was collected before in the main thread.
If we'd expect the plugin developers to program threads like this would there still be a problem with the ForEachXYZ calls?
RE: Asynchronous tasks - xoft - 09-28-2015
There's no simple way to limit the thread's interaction with the rest of the server. As long as there's cRoot:Get():GetWorld() and similar functions, the worker thread could always interact with the main server with disastrous results.
On the other hand, if we remove the entire API form the thread's Lua state, then the thread cannot do any work at all - it wouldn't know how to interact with a cBlockArea and so on.
RE: Asynchronous tasks - NiLSPACE - 09-28-2015
You could change the __index metamethod in _G and other objects of the worker thread. If the thing the worker thread is trying to get is unsafe for multi threading then raise an error.
We'd have to make a list of all unsafe things like the whole cWorld class, cRoot:Get():GetWorld() and stuff
RE: Asynchronous tasks - worktycho - 09-28-2015
There is a way of handling this. We can run tolua multiple times to generate multiple sets of bindings. That would enable us to disable unsafe functions.