Is PocketMine a single-threaded application?

I am not really sure what is the definition of 'threads' here. Does the number of 'cores' and 'threads' in a CPU the same as the 'threads' in PocketMine?

 

Nope, it is multi-threaded.

But it may just end up running on one core, because PHP is weird like that.

 

Wait, then why is other server softwares single threaded? https://www.spigotmc.org/threads/is-minecraft-still-very-single-threaded-best-cpu.74637/

 

Minecraft the game only uses one core because of how it's written.

They are being stricter than me with the definition of "single-threaded". PocketMine doesn't use threads enough to help performance that much (because PHP isn't built for that). Like you could imagine if you had a website, every person loading the site could be on their own core (if you had an arbitrary amount of cores), but PocketMine doesn't use threads that much. There is one main thread and then threads to generate worlds and handle network stuff.

The threading in PocketMine exists to prevent the server from breaking because it's trying to serve clients while generating a world, not to make it blazing fast or anything.

 

The main thread is very very busy and other threads are fairly doing anything [Except the RakLib thread] It is very hard to build a threaded MCPE server, because we have to get all our results together in 1/20th of a secound. We do postpone some stuff like world generation or network compression, but it is nearly impossible to do sth like AI async, due to the large amount of managing and synchronization needed.

 

The main issue with threading is keeping the different threads in sync. The way PHP threading is set-up is that they don't share anything so there is no simple way (built-in way) to keep threads in sync.

Currently in PM, you have one main thread which does most of anything and maintains the in-game state. The other threads that run are used to do things that do not really depend on the main thread state (i.e. world generation, runs independently and once a chunk is built is sent as a whole to the main thread).

In theory it would be possible to make PM more threaded, but it would require a major rewrite (which nobody is willing to do). If I was to make PM more threaded I would do the following:

1. Split the networking to its own thread.
2. Each world becomes one thread. So if you have two worlds in your server, you would have two threads, one for each server. The state of each world is maintained in that thread.
3. Each player becomes one thread. So maintaining the player state is in that thread. You could implement anti-cheat here for example.
4. Entities could become their own threads. If threads are very lightweight, each entity could be on its own thread, so you could have very extensive AI and still not burden the main server with it.

Then you would need IPC to communicate between threads, but it would be more "message passing" (not sharing data, which is difficult with PHP thread). For example, the player threads tells the world thread that it is breaking a block.

 

I've often wondered if crop growth could be handled similarly to world generation. Each chunk crop growth would spin off into another thread and then copy the complete set of changes back to that chunk at an interval that could be adjusted in settings.

I'm sure the complex part is figuring out a good way to handle that communication.

Water flow could be handled in a similar way. Probably NOT lava or fire because you need to be able to run away from it and interact with it in real time.

It would appear more "jerky" to the players; but the performance might be much better for massive worlds with huge farms (factions servers).

 

Threads don't magically give you infinite power. Only Creating a thread probably alteady takes longer than calculating crop growth. Stuff like anti cheat is making the server busy. (Not really only that though)
I talked about this with sofe not a long time ago. We came to the conclusion that the time spent to sync and pass block changes entitiy movements, etc. over would take longer than just doing it in the main thread.

 

Depends on how you are splitting the threads. If the two threads require minimal synchronisation, then you get improvements on a multi core server.
A good example of this would be if you were to split the main thread into multiple threads on a per world basis. (Each world runs on its own thread). Synchronisation between these two threads would be minimal, so both would run at full speed.

 

We are just speculating, obviously I am not planing a PocketMine-MP rewrite.

So each world has its own thread, so world events are handled by that thread. Events that spawn the whole server (across worlds) would need its own way of communication, but in my view, those wouldn't be very common. If we follow the PHP thread model, you would do this through message passing (or equivalent).

 

In a "threaded" scenario, I would make a per-world thread, and world events would be handled in that thread. Plugins can be handled in a number of ways. One way is that plugins are created in the main thread or on its own thread, and you would send events as "messages" to the plugin. This of course means that the plugins themselves need to be thread aware.
Another option would be that you create a plugin instance for each world thread. As long as a plugin doesn't require inter-world synchronization, the existing plugin code would work as is.

 

As soon as you introduce threading you make things more complex, so that raises the bar on what Plugin developers need to know. On the other hand, a plugin developer can start with easy plugins and grow into the more complex plugins.

I agree, that's why ideally the plugin specification should tell the server where the plugin should run (i.e. per-world thread, main thread, etc).

Yes, that is part of the threading overhead. I never wanted to imply that Threading would magically fix all performance problems.

You can make life easier for new developers if you encapsulate the thread synchronization into some common elements that should work for 80% of use cases.

That depends on what the plugin does. For example most Mini game plugins are limited to a single world, so inter-world synchronization is not an issue in those types of plugins.

In my view, per-world thread plugins are those plugins that work heavily with the world environment and/or its state is specific to a single world like mini-games, or the ones that make lots of changes to chunks.

As a threaded architecture I think you could have:

The main thread - handles the networking and communication between the different threads.
1x thread per world for World state. - Manages the world state and sends messages to players/entities in that world.
1x thread per world for AI - handles the entity AI. This would need to have a synchronized view of the world state thread. This can be done the same way players get their view of the world synchronised. And yes, this adds processing overhead and memory consumption.
1x thread per player - (optionally), manages the player state, receives network messages from players and decides what should happen. Anti-cheat code would run here.

Anyway, this is just a suggestion, I am sure the real people in the PocketMine team has good ideas on how this all should work.