Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Fixed race conditions in cClientHandle's State. #3439
Hopefully this PR should fix all the issues seen lately with
Mostly, the change is about adding a
referenced this pull request
Nov 20, 2016
It is, of course, my duty to inform you of both #3115 and the available evidence suggesting that multithreaded access is rarely conducive to a clean and verifiably bug-free codebase.
But yeah, if it closes so many issues, why not? (are you sure they're all to do with the client handle? We shouldn't accidentally bury an unrelated bug)
Yeah, 3115 is our Lord Savior, Hallelujah! :D But the same as the Messiah, it's coming in the future and no-one knows when. Not to mention it's a super-complicated change that no-one trusts.
Yes, multi-threading is rarely clean, but it IS needed. And this PR actually cleans it up, since it clearly defines the conditions for how the clienthandle is to be accessed by multiple threads. And yes, it needs to be accessed by multiple threads - we don't want to do world ticking and chunk generating and network manipulation all in the same thread, do we?
Yes, I've manually gone through all the issues and they all can be tracked back to that race condition.
It's not that I'm hoping for a single thread to do everything, just multiple threads which have obvious places for data input and output, are self-contained, and which do not interfere with each other's state in the middle of their operation.
As they say, if xoft's a dinosaur, then I'm a novice, and novices don't have the experience or ability to trace through the intricacies of complex thread interactions when we want make some protocol change.
Definitely not against a merge. As you say, the other change is coming in the far future. :P
Nov 22, 2016
I don't remember all the details anymore, but I know the issue fixed by this PR was about race conditions in