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