Would anyone be interested in helping to build a lock hierarchy for for cuberite? I was trying to build a patch for a potential deadlock Seadragon91 spotted with the clang thread sanitizer, and I couldn't work out whether the change I wanted to make would cause other deadlocks.
Also could we eliminate cCSUnlock by providing a cEvent.Wait(Lock) overload which unlocks the lock whilst it is waiting? Then we could use clangs thread safety annotations to help avoid deadlocks. There are are only two places in the codebase that are using cCSUnlock around something else.
What kind of help do you need? Coding? Debugging? Something else?
More just would anyone else use/follow it. If we do it in code, would the PR be accepted, given tools like clangs thread sanitizer provide the same guarantees. And if we did it outside the codebase, would it actually be used/followed, given how easy it is to call a method that calls a method that calls a method which takes a lock.
I don't think we could ever build a proper hierarchy, because of plugins. Each plugin has a lock and can acquire the world lock during its execution, and on the other hand world ticking does call into plugins while the world lock is held. I don't see a simple way out of this.
We could however ensure that c++ code follows the hierarchy. And really we should have runtime checks causing API calls to fail if plugins don't follow the hierarchy.
Debug builds suddenly got a LOT more verbose. What's up with that?
The new Redstone simulator is spamming the console in debug mode.
Pity, I wanted at least something Cuberite-special