Proposed change to the Interplugin communication API

[worktycho]

The Plugin object may still exist but that doesn't mean that the plugins internal state is valid, if the plugin has caused a backtrace in means that there is something wrong with its state and carrying on is likely to lead to corruption and hard to debug errors, similar to the issues caused by on error resume next in vb and C++ heap corruption bugs. There are two types of errors, recoverable and fatal. Fatal errors should cause all data to be replaced in addition to the current execution path as something has gone wrong with the programmers assumptions, eg Assert failures. recoverable errors require that the program actually do something to fix its state so that the recoverable error is not repeated. For example in the database error the program needs to rollback whatever it was working on or it will be in a state the programmer did not expect. If a plugin causes a stacktrace and does not do anything to handle it, which it cannot in the current interface the only option is for MCServer to clear the state and reinitialize the plugin which causes the creation of an invalid plugin object.
I'm trying to change some things that are broken(exposure of locking in interthread communication and threadguarding hook objects) whilst also improving some things that are not broken but cause unexpected issues.

[xoft]

Actually, no, for Lua the state is pretty well defined and it is recoverable very nicely. There are no heap corruption bugs etc. Yes, it's not ideal when that happens, the plugin may have been halfway through some work, may have set some internal state, but I think reloading the plugin may be equally as bad, so there's no real advantage there.