01-12-2014, 02:19 AM
Alright, clarification time.
What do you mean by plugin crashing? There are three behaviors that could be considered a crash:
1, The plugin's code is syntactically incorrect. Lua will complain when the plugin is being loaded and the plugin is never actually loaded. cPluginManager:GetPlugin("foo") returns nil, because there's no such plugin loaded.
2, The plugin's code misbehaves (such as breaking on an assert, calling a non-existent function etc.) while initializing. Again, such plugin will never be loaded, so cPluginManager:GetPlugin("foo") returns nil.
3, The plugin's code misbehaves (such as breaking on an assert, calling a non-existent function etc.) while executing, either a hook callback or a call from another plugin. Lua will unwind the full Lua stack, returning to MCServer; MCServer prints an error message. The plugin is valid and any hook or inter-plugin call can still go through (and possibly succeed).
Now, which ones are solved by using a plugin handle? Obviously #1 and #2 aren't because the plugin won't even load. The plugin handle will make things worse, because it will keep asking MCS to load a plugin that MCS just cannot load.
In #3 the plugin object stays the same and is still usable, so there's really nothing to solve. The only benefit could be the OnPluginCrash; how would that be used by the plugins? Is it a hook, or is it a callback function that the plugin specifies when getting the plugin handle? What if a cascade of crashes happens - plgA calls plgB and plgB calls plgC for some sub-work; plgC crashes and plgB's crash handler crashes too. Ouch!
What I see as a benefit of having a PluginHandle is per-plugin load, unload and reload. Currently if we wanted to implement reloading a single plugin, while keeping the other plugins running, there would be a problem because any of those running plugins may hold a pointer to the plugin being unloaded. That pointer would effectively become invalid and the plugin caught using it will most probably crash the server (if lucky). With a PluginHandle, the situation is somewhat better - the plugin holds a PluginHandle and when reloading the plugin, the internal Plugin object will be swapped inside the PluginHandle. This works nicely, *but*: How about plugin unloading? There's no replacement plugin instance coming into the handle, what now?
Another concern of mine is the need for explicit locking and unlocking. When you force the plugin writers to do something like this, you can be pretty certain that some day someone will forget, or just try what happens if they don't do it. And all hell breaks loose.
What do you mean by plugin crashing? There are three behaviors that could be considered a crash:
1, The plugin's code is syntactically incorrect. Lua will complain when the plugin is being loaded and the plugin is never actually loaded. cPluginManager:GetPlugin("foo") returns nil, because there's no such plugin loaded.
2, The plugin's code misbehaves (such as breaking on an assert, calling a non-existent function etc.) while initializing. Again, such plugin will never be loaded, so cPluginManager:GetPlugin("foo") returns nil.
3, The plugin's code misbehaves (such as breaking on an assert, calling a non-existent function etc.) while executing, either a hook callback or a call from another plugin. Lua will unwind the full Lua stack, returning to MCServer; MCServer prints an error message. The plugin is valid and any hook or inter-plugin call can still go through (and possibly succeed).
Now, which ones are solved by using a plugin handle? Obviously #1 and #2 aren't because the plugin won't even load. The plugin handle will make things worse, because it will keep asking MCS to load a plugin that MCS just cannot load.
In #3 the plugin object stays the same and is still usable, so there's really nothing to solve. The only benefit could be the OnPluginCrash; how would that be used by the plugins? Is it a hook, or is it a callback function that the plugin specifies when getting the plugin handle? What if a cascade of crashes happens - plgA calls plgB and plgB calls plgC for some sub-work; plgC crashes and plgB's crash handler crashes too. Ouch!
What I see as a benefit of having a PluginHandle is per-plugin load, unload and reload. Currently if we wanted to implement reloading a single plugin, while keeping the other plugins running, there would be a problem because any of those running plugins may hold a pointer to the plugin being unloaded. That pointer would effectively become invalid and the plugin caught using it will most probably crash the server (if lucky). With a PluginHandle, the situation is somewhat better - the plugin holds a PluginHandle and when reloading the plugin, the internal Plugin object will be swapped inside the PluginHandle. This works nicely, *but*: How about plugin unloading? There's no replacement plugin instance coming into the handle, what now?
Another concern of mine is the need for explicit locking and unlocking. When you force the plugin writers to do something like this, you can be pretty certain that some day someone will forget, or just try what happens if they don't do it. And all hell breaks loose.