Posts: 6,485
Threads: 176
Joined: Jan 2012
Thanks: 131
Given 1074 thank(s) in 852 post(s)
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.
Posts: 783
Threads: 12
Joined: Jan 2014
Thanks: 2
Given 73 thank(s) in 61 post(s)
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.
Posts: 4,628
Threads: 115
Joined: Dec 2011
Thanks: 693
Given 494 thank(s) in 423 post(s)
09-28-2015, 08:10 PM
(This post was last modified: 09-28-2015, 09:49 PM by NiLSPACE.)
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?
Posts: 6,485
Threads: 176
Joined: Jan 2012
Thanks: 131
Given 1074 thank(s) in 852 post(s)
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.
Posts: 4,628
Threads: 115
Joined: Dec 2011
Thanks: 693
Given 494 thank(s) in 423 post(s)
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
Posts: 783
Threads: 12
Joined: Jan 2014
Thanks: 2
Given 73 thank(s) in 61 post(s)
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.