Will Sponge support multi-threading?
I am afraid you will have to ask this to mojang/microsoft.
But its possible: https://github.com/nallar/TickThreading. But this isnāt something sponge has to cover. Also TickThreadings isnāt developed anymore ;-;.
https://tridentsdk.net/ did try and tackle threading from memory. Unsure on how far they got but when I last looked (December?) They had made some decent progress on Memory and CPU optimisation.
The vanilla version of sponge (Granite) could do this, correct me if Iām wrong. Glowstone could also, know that I think about it.
Nope, your confusing granite with craftbukkit. Also granite and the forge implementation have some of the mixins in common. But I donāt think multithreading is something Sponge will address in its early stages. I mean, its already complicated enough will all these mixins classes. If you add the complexity of multiple threads with it, ā¦ ehm idk what would happen. It wouldnāt be easy for an outsider to understand the sponge code (what it already is).
minecraft doesnāt support multithreading on its own. hell, with the code jungle minecraftās src already is, i donāt think itād be a concept easily feasible without an entire rewrite of the base game, which we donāt expect Mojang to do any time soon, do we?
3 Likes
It doesnāt need a complete rewrite. A rewrite of the Tick Engine could be helpfully.
Basicly I would see every spot of loaded chunks as a Thread that gets synchronized and timed on the Main server thread.
If a Thread is stalling it simply skips ticks (Like the server does with a canāt keep up). So can some people on the other side of the world fire off 50K of TNT without lagging other people.
And if 2 threads merge. The first thread just takes over the chunks of the old thread. And that old thread goes to sleep or kills itself. Not sure if this could give lagg spikes. But ofc that the problem of the person who wants to implement this 
.
Now minecraft just has a list of loaded chunks and iterates 20 times/sec.
But if we include sponge with this. Plugins would need to encounter the fact that Events are multithreaded. Making plugins wouldnāt be that easy anymore. And you would get CurrentModificationException all over the place ;-;. People may think MultiThreading is awesome, but for devs its a pain in the butt. Lets hope some dude finds a way to simplify this process. Same as OO came alifeā¦ .
7 Likes
Heās not confusing Granite with CraftBukkit. Why would you think that CraftBukkit is the vanilla implementation of Sponge, anyways?
Heās saying that Granite could support multi-threading, as itās an entire server (whereas Sponge is a mod for FML, which doesnāt support multi-threading (that I know)).
Glowstone was definitely working on it, I believe. Especially considering that they didnāt rely on any Minecraft server code at all.
2 Likes
Right on the point
I thought me meant that Granite only could do this. What was the case with craftbukkit. What I am trying to say is. That if their are mixins for it. It will normally work on the forge implementation tho. (If we ignore the fact that some forge mods may not like it.)
Your overuse of the period has completely flummoxed me.
CraftBukkit didnāt support MultiThreading. Iām not entirely certain why you think it did.
And as it is, Sponge will not support MultiThreading. Granite probably wonāt either, given that it uses Minecraft server source, but it could. Glowstone, on the other hand, was an entirely new product to emulate Minecraft client connections, without actually using any of the base Minecraft server code, which means it could have easily been multithreaded.
Sponge cannot support MultiThreading, because itās just a mod. Forge would need to support it, which is unlikely.
Just searched for āthreadingā, perhaps these may be useful
1 Like
Maybe they are mistaking the Bukkit async tasks for multithreading? I will admit the docs for all of Bukkitās Async stuff did make it sound like they were on a separate thread.
Like this (Taken from the Bukkit APIās AsyncPlayerChatEvent docs):
When asynchronous, this event can be called from any thread, sans the main thread, and has limited access to the API.
I suppose, to be fair, the Bukkit docs could have been better written to specify exactly how Asynchronous actions work.
When you run something Asynchronously, all it natively means is that the thread doesnāt wait for a response (which is why you should beware ConcurrentModificationExceptions when modifying values from outside the asynchronous class).
EDIT: Though, it is worth noting that some asynchronous implementations can be done via threading, this doesnāt necessarily mean that Bukkit supported multithreading.
I had read somewhere that craftbukkit runned (extra?) worlds multithreaded. But I am afraid I have been fooledā¦ . (And I canāt check it anymore either). But thinking about the api, its not likely that was the case. Sorry, I was misunderstanding it.
Nope!
All world processing is on one thread, per Mojangcode. Only a few things occur on separate threads.
3 Likes
Wasnāt one of the recent updates supposed to do something to world ticking? I thought I saw that somewhere.
From August of last year, you mean?
Maybe? I might be wrong but I swear I saw on Mojangās site that they were doing something to world ticking.
I thought we were still talking about CraftBukkit, lol.