Up to Main Index Up to Journal for November, 2021 JOURNAL FOR SUNDAY 28TH NOVEMBER, 2021 ______________________________________________________________________________ SUBJECT: Server configuration DATE: Sun 28 Nov 17:02:29 GMT 2021 The second beta snapshot v0.0.19-beta.2 was released. No screaming or angry emails, so I assume it went well. I did have a journal entry ready to publish about a week ago. However, due to complications it became irrelevant… I’m working through the known issues and bugs. At the moment I’m looking at adding the capability to configure the server via the data/config.wrj file. Previous versions of WolfMUD handled the server configuration badly. So badly it came back and bit me in the arse when Go 1.13 was released and there was breakage due to Go issue #31859. Sometimes it’s too tempting to code your way down the easy route. This time I wanted to do a better job. You would have thought that configuration would be easy right? Not so. I’ve been browsing around for inspiration and found lots of examples of what not to do. There are many ‘opinions’ of what you should do, but few concrete examples on how to do it. There is one awful example of a singleton using package level variables, init functions and double locking that seems to have been copied and rehashed all over the net :| I had many failed attempts. Either the locking overhead, method calls to query settings or memory allocations killed performance. Complexity was also a factor. Trying to pass configuration along through parameters, somewhat like passing a context around, things became very messy. I didn’t want every player or item to have a pointer to the configuration, that seemed too wasteful. So I had a long, hard think. What I wanted was a lock-less solution without using init functions or a single global configuration — as that leads to “spooky action at a distance” due to hidden dependencies. I settled on an unorthodox ‘immutable’ package level configuration. It’s immutable due to the fact configuration is created and never changed. This enforced immutability has made configuration simple to implement, concurrent safe and lightweight, although it is a little ‘spooky’ still and not perfect. I’m not sure how well it will work with the testing framework, or that you should reuse it as best practice. However it is working and easy to rip out and replace at a later date if needed. I’d like to show some example code here, but everything is still up in the air and being worked on :( There is plenty of testing and everything is being run under the watchful gaze of the race detector. So far I have had the server running and restarted a few thousand times without any data races… -- Diddymus Up to Main Index Up to Journal for November, 2021