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?
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?