wtf

[jfray]

There should be a global read/write lock on the json config files to avoid any concurrency bugs around that file. Too much depends on it. What I'm thinking is a locked reader/locked writer implementation that conforms to reader/writer interfaces. All reads and writes of that file from any part of the code would then need to use that to get to thingss. By doing that, I can enforce that when someone is writing the config that no-one can read it and will be delayed, or that writing can only happen when all reads have completed. Something like that anyways.

Another option here is that the config json is cloned before read so that each process is using its own version of the file as an immutable thingie. Due to the atomic nature of the file save, while someone is writing the file they will either have the previous version or the new version, but should never have an intermediate version. All of this stufff will need tests, as I mentioned in #12

Here's my current thinking:

• use the conf.json files as an intermediary user-friendly config file that can be accessed by other applications if needed (main reason I chose JSON in the first place)
• watch the file for changes using inotify or somesuch - if the file contents change, trigger something
• that trigger of something could be a dump of the k/v into sqlite or something nice and tiny and easy to work with

Crazier ideas:

• Some kind of config mgmt framework? Can I use etcd for this? What would that look like?
• use that cool iniflags extension for golang that allows you to watch a config key and trigger something if it changes
• whatever we do, it's gotta be safer than what I'm doing now.

[jfray]

I'm not sure why this happened when I asked for a new issue. it's an exact dupe of #14. Closing this shoop noop.