+- Cuberite Forum (https://forum.cuberite.org)
+-- Forum: Plugins (https://forum.cuberite.org/forum-1.html)
+--- Forum: Plugin Discussion (https://forum.cuberite.org/forum-8.html)
+--- Thread: cPluginManager:GetLuaPlugin() and lua_State (/thread-467.html)
RE: cPluginManager:GetLuaPlugin() and lua_State - FakeTruth - 06-09-2012
(06-09-2012, 07:35 AM)FakeTruth Wrote: Yeah, sending messages is totally possible, because you can queue them and handle them in the tick function or something. But that means you cannot immediately get a value back
I think a message system is completely useless.
What if, for example, you have a separate permissions plugin next to MCServer's built in permissions, and your plugin needs to query the permissions plugin to see if the player can do a certain action. The hook requires you to return with a decision immediately, but with a message system you cannot query the permissions plugin and return a definitive decision in the same hook call...
A solution might be to use a single CriticalSection for all plugins, that way there wouldn't be any locking between plugins. But this can also create a deadlock in certain cases I think...
RE: cPluginManager:GetLuaPlugin() and lua_State - xoft - 06-09-2012
Messaging could be used for that, if we implement blocking messages (SendMessage() equivalent) - the message sending returns only after the message is delivered and processed by the destination, and a result can be returned.
RE: cPluginManager:GetLuaPlugin() and lua_State - FakeTruth - 06-09-2012
(06-09-2012, 09:34 PM)xoft Wrote: Messaging could be used for that, if we implement blocking messages (SendMessage() equivalent) - the message sending returns only after the message is delivered and processed by the destination, and a result can be returned.
And how does this not cause deadlocks?
RE: cPluginManager:GetLuaPlugin() and lua_State - xoft - 06-09-2012
It needs to be carefully implemented. I'm not saying it can't, but somehow Windows does it, so we should be able to do it as well.
RE: cPluginManager:GetLuaPlugin() and lua_State - FakeTruth - 09-26-2012
xoft, do you think if all plugins would share the same critical section a deadlock can still happen when one plugin calls a function on another plugin?
Take these two plugins
PluginChat: Hooks into the player chat
PluginPermissions: Can be used to check player permissions and does weird stuff
Handle packet thread
1. OnChat -- Lock plugin criticalsection
2. PluginChat:OnChat
3. Call PluginPermissions:CanChat()
4. PluginPermissions:CanChat() decides to loop over all entities/players to find out whether the player is allowed to chat ( ???
)5. Waiting for Entity list lock (Tick thread owns this lock)
Tick thread
1. cPlayer:Tick() (player takes damage from hunger) -- Entity list/critical section is locked
2. OnTakeDamage
3. Waiting for critical section on plugins (Handle packet thread owns this)
And voila, deadlock.
EDIT: Man, this could even happen if it was a single plugin... which means this deadlock is in MCServer RIGHT NOW
RE: cPluginManager:GetLuaPlugin() and lua_State - xoft - 09-26-2012
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.
RE: cPluginManager:GetLuaPlugin() and lua_State - ThuGie - 09-26-2012
Or like you could call it a feature
.Microsoft and other software company's have done that for ages
.Anyway glad you guys found this before it became a problem :p.
Now just hope you guys can fix it before it does become one haha.
RE: cPluginManager:GetLuaPlugin() and lua_State - xoft - 09-26-2012
There's no way to "fix" this other than making sure plugins authors have a way around it.
RE: cPluginManager:GetLuaPlugin() and lua_State - ThuGie - 09-26-2012
Ah i see,
And is there a way for the server itself to run a check on the plugin if its actually using a way around it ?
RE: cPluginManager:GetLuaPlugin() and lua_State - FakeTruth - 09-26-2012
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
(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