Hello all, I’ve got some interesting discussion topic here about bringing asynchronous approach for MC processing.
Idea came to me, while I was looking into others attempts to make server faster.
I was particularly looking into use of multithreading, as in my opinion the weakest part of mc is doing it all in one thread.
Right of the bat, the idea: unattached loaded parts of the world can not affect each other and can be processed separately.
Look at this simplified map of the world.
Steve face - player
Greed cells - loaded chunks, entity processing
Yellow cells - loaded chunks, lazy
Regions, that are not touching each other can not affect each other in any way. No entity, or block update can traverse unloaded chunks.
Of course there are some ways to load more chunks, like placing on borders redstone, hoppers, fire (causes problems in nether), etc. But lets keep these things out for simplification the discussion, as the topic is about separate regions, which will be there anyway.
So basically I image architecture, where main thread is busy, by allocating tasks for threads.
Each thread is busy by processing its part of the world.
Sometimes there will be event of merging two separate processing regions, and that should be handled my main thread, by merging two tasks in one and keeping in in one of two thread.
Idea looks elegant to me, and this makes it too suspicious - why wasn’t it implemented yet?
So I want to discuss here, what possible problems might such approach bring.
My thoughts on possible problems:
- Difference in tick count in separate threads.
One thread my throttle with some fancy redstone lag-machine and fall behind others. But is it really a problem? It is perfectly fine, as separate loaded parts do not affect each other.
The only thing, that should be identical for whole world - time of day. And this can be handled by main thread.
Funny enough, its the only thing, that I come up with, that can traverse between two separate regions.
You keep your dogs sit some where and leave. When somebody else drop water on them, they should teleport to you, whereever you are in the same world.
Funky staff. Can be handled as portals in next point - transfer data between tasks.
- Other worlds chunks.
This is trickier. Chunks in nether can be loaded by using a portal. Even when through an item in it.
Either such chunks should be in the same task as chunks overworld.
Or it is in separate task, and usage of portals should be handled differently to pass data from one task to another.
- Scoreboards and other server-wide data.
Can be handled by main thread and be accessible as readonly for tasks.
What are your thoughts?
What do you think of other problems that can emerge?
Some background about my reasons and capabilities.
I’ve got decent programming experience in mainstream languages like python, C and C++ through 6 years of work, but my Java skills are really limited down to couple plugins, I wrote this year for my friends server.
Holidays are coming and I want to make this project as a week-long learning session for myself to grow my grasp on Java, multithreading and spigot internals in particular.
If it will or will not work, I will be happy, but I don’t want to spend so much time and effort, if the idea if flawed in its cradle. It will be just frustrating and teach me too little.