Hi, Is there any interest in making PocketMine more threaded? (i.e. use more threads so that multi-core systems can be better used?) I know the current focus is on MCPE 0.11 and biomes + entity physics. However a big change like this is better done earlier rather than later. What is the general thinking about that?
PocketMine 1.5 is going to have support/APIs/libraries in easier use off threading, according to @shoghicp.
What I was thinking is that maybe we should have one thread per player, and one thread per level. Data sharing is mostly done on a per level basis. (i.e. normally players interact with each other through the Level). On the other hand, a lot of plugins and anti-cheating is done on a per player basis (i.e. checking what a player does and execute something).
That would be terrible. A lot of possible race conditions. And possibly memory issues because of having many threads. Moreover, pthreads itself is buggy in OOP. Doing that would lead to disastrous bugs.
Not necessarily. if we start first by having one thread per level, that thread should manage all access to the level. Since this is done through a well defined API, then it should be no problem to encapsulate. It is very rare when an operation would need to access/manipulate data from multiple threads/levels. So each thread can easily run independently without sharing any data. Players could be done with worker threads. Normally a lot of the processing (specially done by plugins) would be manipulating player input (which is not shared with other threads) or reading state from the Level (which would be done through the API to get data from the Level thread). If for example you are doing anti-cheating code, then the input is cancelled (a packet is sent to the MCPE client) and nothing is changed on the level data. On the other hand, if the input is allowed, then it is modify operates are handed over th the Level thread to apply. Essentially, the idea would be to not share data, and let controllers running on threads do all changes.
Let's not have another API major version bump so soon after the havoc that was transitioning from 1.3 to 1.4 xD
I would love to make PocketMine work on a thread per level! But plugin developers would hate it, and it would break backwards compatibility (worst thing I did since API 1.0.0 was deprecating an Event and do not fire it). PocketMine 1.5 has lots of threading improvements, for plugin developers and normal usage. World generation, chunk population, and network compression will use the Async workers (so increase this if you want to use more of your resources!). Threads have a proper class loader that is shared across all of them (no need to manually include files on threads). So, in 1.4, this was the list of threads: Main thread Console I/O (mostly idle) RakLib thread Logger thread (mostly idle) Generation thread (one for all worlds) Async Workers [one or more] (used for AsyncTasks, mostly plugins) In 1.5, however, it changes completely: Main thread Console I/O (mostly idle) RakLib thread Logger thread (mostly idle) Async Workers [one or more] (Now with shared class loader, and per-thread data saving) Generation tasks Population tasks Compression tasks Plugin tasks The only overhead now is chunk serialization, which is needed by phreads. Also, more threads != more performance always.
I think running too many threads is a very bad practice. PHP is already a slower language than others. Then you have to consider also the max number of threads for task supported by OS and CPU
Yep! Lots of people don't understand threads and just set the async worker count to 1000 or something bigger ("It'll be faster, and I have a XXX Ultra Pro PC") then they blame me because they hit the OS thread limit per process. And what I've done is run more on less threads. They async workers will get reused for everything, so they are well used if set to a proper count.
