search

GlowstoneMC / Glowstone

A fast, customizable and compatible open source server for Minecraft: Java Edition
https://glowstone.net
Other
1.9k stars 273 forks source link

Glowstone support Multi-threads? #420

Closed jawaw closed 7 years ago

jawaw commented 7 years ago

Glowstone support Multi-threads? Paper and Glowstone ,I don't know the which one is faster.

mastercoms commented 7 years ago

Are you asking if Glowstone uses multithreading? Or are you asking if Glowstone is thread safe (can be used by plugins in threads)?

jawaw commented 7 years ago

I mean,does glowstone support load blocks and computing entities uses multithreading?

mastercoms commented 7 years ago

Right now we don't have entity logic, but blocks do have a threaded pulse.

jawaw commented 7 years ago

OK, I see. If Glowstone will only support for Vanilla Minecraft in the future?

gdude2002 commented 7 years ago

We are aiming for feature parity with vanilla, but it's a slow process and everything needs to be done by hand.

mastercoms commented 7 years ago

Discussion seems to be over, so closing.

nova-nowiz commented 4 years ago

Hello! Sorry for necroing on this issue but I didn't want to open a new issue for the same discussion.

I recently discovered that Minecraft servers are, for most or all game logic, single threaded. This is particularly a problem for survival servers as it limits the number of players to about 200 max.

I didn't find much information on forums and the internet in general on the difficulties that one might encounter while implementing multi-threading for the game logic server side. I was wondering if as maintainers of this project, you had any inside of what would be the blocking points? Furthermore, is it a move that can only be taken first by Mojang for compatibility reasons?

A248 commented 4 years ago

One point of contention (no pun intended) would be the Bukkit API's assumption of a main thread. As Glowstone intends to implement the Bukkit API in order to allow access to the broad base of plugins using it, this assumption would be a thorn in a more multithreaded implementation.

The difficulties one might encounter adding threading to any program are manifold. Multithreaded programs are much more complicated, requiring careful concentration and attention relating to preventing race conditions, ensuring synchronisation to shared data, and avoiding deadlocks.

Shevchik commented 4 years ago

While Bukkit does assume that something like main thread does exist, it doesn't expose this directly. The only method that does it - Bukkit#isPrimaryThread can be always patched to return whatever (and even it's documentation states, that it's about the synchronized state of the runtime, and not about some specific thread) The scheduler and events use a concept of sync/async, where sync is a state which is synchronized with server runtime (so it's safe to call world/entity/block/etc methods), which means that you can implement it however you wish, as long as you make it safe to call those methods from other sync tasks and events. The only issue is that sync events synchronize on plugin manager, so only one thread can process the event at the same time, which means that you still have this one bottleneck. But you can solve this by adding an concurrent event processing capable marker to PluginDescriptionFile, and fire non sync events if all plugins that listen to event are concurrent capable.

nova-nowiz commented 4 years ago

Very interesting responses... I understood that the implementation makes it theoretically possible to implement async events but plugins are the bottleneck in that case as they poll from a singular event thread (correct me if I'm wrong x)).

I don't really know to be honest the architecture of a minecraft server so I don't know what the scheduler and events are responsible for. I would guess that events are everything that happens in the server (from all players?). For the scheduler, I know the broad usage of a scheduler but didn't study it yet so I don't know how it works in details but I guess that it's not the problem here as from what I can tell it allows async events (do not hesitate to correct me if what I'm saying makes not sense x)).

You said at the end of your text that if all plugins are concurrent capable, it would be possible to fire async events. IMHO, even if implementing async events changes the plugin API, a good majority would follow. Particularly survival, anarchy, events and rpg servers... everybody is either stuck on 1.12.2, limiting the player base, or dividing their server into smaller ones for this reason. If async events raises their player cap, they would go for it

I'm not particularly good at java as I did not use it professionally and I don't know the codebase but I'm willing to help on this topic as much as possible

A248 commented 4 years ago

Plugins still assume a single thread even if Bukkit never explicitly states it. I know for one I've cached the Thread instance of the main thread in some of my plugins, in order to workaround limitations in the Bukkit scheduler. I've seen several others do the same and I'm not surprised.

Very few plugins are actually built to be thread safe. Overhauling existing plugins and programs to work in a multi-threaded environment requires so many changes to existing code, that it is almost a pre-requisite to write concurrent structures from the beginning. Many things would need to be rewritten entirely, depending on how biased their design is toward a single-threaded environment.

Events can be run asynchronously, but only if they are marked or enabled as such before-hand. Events can be flexible with regards to their thread context, but only if they are made that way before-hand. The vast majority of Bukkit events are fixed as synchronous.