WORLDEDIT-2200 - Reported by root

Split off operations so that they can easily be chunked, and allow some to be asynchronously run when possible.

Comment by Chris.Woo

It wouldn't work as a separate thread? Thought it would help haha

Comment by sk89q

Nah. Minecraft won't wait for WorldEdit (or anything else) to make a change, so imagine a block is being set in the main thread, but halfway through, WorldEdit sets it too, but right before the main thread finishes setting it. Who knows what could happen, and that's just a relatively simple example. There are much more dangerous examples :)

Normally "thread-safe" code handles this by employing "locks" on regions of code, so only one thread or process can use it at one time. MC does not employ locks for the majority of it.

Comment by Chris.Woo

Ah that makes sense! Still looking forward to the day that I can do 1 Mil operations without the server locking up :D

Comment by Chris.Woo

Would this help?
Bukkit/CraftBukkit@53ad0cf

Comment by wizjany

bumping the issue wont speed anything up

Comment by Chris.Woo

And who are you? Anyways I havent looked at sk89q's codebase yet. From what I understand from making an OS, executing tasks like WE operations can be split into smaller, asynchronous, non-blocking chunks. If sk was going to make a class to do that, I'm not sure if he could use bukkit's class to be more robust and save on coding and testing time.

Comment by wizjany

Dev here, Hi.

Comment by Chris.Woo

Admin and avid scripter here, Hi. Nice to meet you :) Titles aside, if it's useful, it should be used. If not, then whatever.

Comment by falkreon

The scheduling part is easy. Also, the scheduler you linked is hidden behind the OBC/NMS version-wall, so it's nearly useless to WorldEdit's team.

The problem with WorldEdit, my main problem, is that it's got a lot of deeply-ingrained code that does all its work in the same method, on the main thread, no matter how long it takes. This can displace the processing of player packets, effectively locking up the server until the operation finishes. Obviously the processing still needs to happen on the main thread, but once the code fully switches over to Operation and ColumnVisitor, it won't be too hard to control how much or how little of it gets done during a given tick.

Defnitely check out the operations-redux branch, and if you want it to happen faster, talk to these folks and write code that they're looking for.

Comment by Chris.Woo

Why don't you move that section of the code to a processing task? It will take some refactoring, but this will allow you to feed in chunks to be processed. I'm not sure how much refactoring is needed to be done for this to work.

Comment by wizjany

we have this under control, it's all planned and mostly written, we just have to get some time before it is finished
thanks for all your suggestions and so on, but they're really not necessary (also most people have no idea what they're talking about)

Comment by sk89q

In progress again, with new branch
https://github.com/sk89q/worldedit/tree/visitor

Only this time, a bulk of the work is done.

Comment by sk89q

The current work can be found in the branch:
https://github.com/sk89q/worldedit/tree/operations-redux

Comment by Chris.Woo

I saw this in a bukkit build, would it help? "runTaskLaterAsynchronously"

Comment by sk89q

Nah, because asynchronously means that it runs parallel with Minecraft, and Minecraft isn't built to handle that. It would completely break the server unfortunately.