Is the MCServer design flawed?
Should we impose more limits on threads?
For example don't allow the packet handling thread to lock entities and ONLY allow the tick thread to do that?
This would force the chat to be handled on the tick thread since plugins tend to do something with players/entities when a command is entered.
Because of the plugins and that multiple threads are calling functions on plugins, each of these threads have access to the entire MCServer codebase (you don't know what plugins are gonna do), while they should be limited to what matters to them.
A solution would be to only use plugins in a single thread but this will create some other issues
And this is only one example, I'm sure there are more scenarios where the plugins can (and will?) create deadlocks
Should we impose more limits on threads?
For example don't allow the packet handling thread to lock entities and ONLY allow the tick thread to do that?
This would force the chat to be handled on the tick thread since plugins tend to do something with players/entities when a command is entered.
Because of the plugins and that multiple threads are calling functions on plugins, each of these threads have access to the entire MCServer codebase (you don't know what plugins are gonna do), while they should be limited to what matters to them.
A solution would be to only use plugins in a single thread but this will create some other issues
(09-26-2012, 05:05 PM)xoft Wrote: Yes, this is completely possible. Luckily we don't have that many that complicated plugins so we haven't run into a deadlock yet, but sooner or later, it's gonna happen and we're gonna have to solve that.It might have happened before already. All that is needed is a plugin that handles commands (like a kick command) and a plugin that uses the OnTakeDamage hook (it can even be the same plugin). Even though it's a small window the deadlock can still occur.
And this is only one example, I'm sure there are more scenarios where the plugins can (and will?) create deadlocks