What this PR does:
Introduces a new way to detect changes in the runtime configuration file using file notifications. The underlying library used,
fsnotify, supports multiple platforms, but I've written this largely with Linux's
inotify in mind.
After initialization, instead of continuously reading a file every reload period, reads are not performed until a change actually happens. Runtime configuration changes are often rare and initiated manually, so it wouldn't be uncommon for no notifications to happen at all. From a thread perspective, an OS thread is blocked on an epoll wait system call with an infinite timeout waiting for event notifications from inotify. If an event is detected on the runtime configuration file a read loop is initiated until a successful read occurs, then it reverts to waiting for another notification.
The benefit of these changes is reducing unnecessary CPU work and unnecessary IOPS. It could allow for users to set a shorter reload period duration if they were unwilling to pay the cost of many background reads previously.
The downside of these changes is the complexity. The kernel has to know about the file changes, so a file stored in NFS or FUSE can deliver no notifications at all. The notification watch is also based on an inode rather than a name, so the directory containing the runtime configuration file is watched rather than the file itself to catch replacements. This leaves the possibility that the directory itself could be replaced, or even mounted against, both of which are currently unhandled. If the runtime configuration file is placed in a busy directory, this could also result in even more CPU work than polling. I also can't speak to the performance or behavior of other platform implementations.
I'm testing these changes still, but wanted to open this draft PR early for feedback given the tradeoffs. My thoughts are that this could be interesting if there is a known workflow for runtime configuration updates and this is tested with that workflow beforehand. Otherwise, I wouldn't recommend this be used.
Which issue(s) this PR fixes:
- [x] Tests updated
CHANGELOG.md updated - the order of entries should be