PocketMine 1.5 is going to have support/APIs/libraries in easier use off threading, according to @shoghicp.

Perfect solution for forum disputes:

Gulliver's Travels said:

You take a hundred leaders of each party; you dispose them into couples of such whose heads are nearest of a
size; then let two nice operators saw off the occiput of each couple at the same time, in such a manner that the brain may be equally divided. Let the occiputs, thus cut off, be interchanged, applying each to the head of his opposite party-man.

Click to expand...

Press the like button if I helped!I respect your freedom of speech, so don't click if you don't want to

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).

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).

Click to expand...

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.

Perfect solution for forum disputes:

Gulliver's Travels said:

You take a hundred leaders of each party; you dispose them into couples of such whose heads are nearest of a
size; then let two nice operators saw off the occiput of each couple at the same time, in such a manner that the brain may be equally divided. Let the occiputs, thus cut off, be interchanged, applying each to the head of his opposite party-man.

Click to expand...

Press the like button if I helped!I respect your freedom of speech, so don't click if you don't want to

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.

Learning Security Noob. If you want your stuff secure from the basic stuff just pm me.Aoccdrnig to a rscheearch at Cmabrigde Uinervtisy, it deosn't mttaer in waht oredr the ltteers in a wrod are, the olny iprmoetnt tihng is taht the frist and lsat ltteer be at the rghit pclae. The rset can be a toatl mses and you can sitll raed it wouthit porbelm. Tihs is bcuseae the huamn mnid deos not raed ervey lteter by istlef, but the wrod as a wlohe.

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.

Click to expand...

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).

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.

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).

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

Click to expand...

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.