Calm down, people.
zerver: ok well just a quick thought about ways to make MT more noob friendly
zerver: it has issues with LUA draw call-ins slowing down the whole game
zerver: so my thought was whether to by default disable all such call-ins for MT
zerver: and the user has to enable it via confighandler
zerver: the question is if this gives more or less bug reports
Tobi: doesn't that imply mt will only be useful with BA?
That basically meant, "I'm having so many problems with MT desyncing or eating massive CPU due to communications overhead that I am considering a major change to it that will probably mean it's no longer all that useful for mods / games using a lot of Lua visuals".
Hence why I said, "gee, maybe it's time for a different strategy here", to which I was told, "well, a lot of things need direct access, and we don't have a good solution yet".
IOW, it's not a conspiracy or anything. It's a technical problem. I get the impression that zerver is pretty frustrated- it all works
, technically, but performance is disappointing
and the desync problem can only be solved by things that defeat the whole point of going MT in the first place.
Another idea about this, btw: maybe run two entirely seperated instances of Lua, one synced, the other not, and let all calls from synced to unsynced Lua in single-thread get queued?
I keep thinking there's got to be a way to put a firewall of sorts between the two areas, operationally. If that means that there is even an "unsynced Lua" instance that has a reduced feature-set, or operates differently (for example, can do calls to UnitPosition, but only with the data from the last synced update), then that's a choice we need to look at.
Otherwise I'm inclined to say that we need to move towards making the engine and Lua multithread-aware, and discuss how that would effect coding for it, and simply drop the idea of two-processor Spring and move directly to multiprocessor Spring.