Consider using inotify in Linux instead of polling for file changes

[jessezamora]

I only mention this because in reading the documentation, the default method of reloading the config files for JSON and YAML is by polling:

https://swiftpackageindex.com/apple/swift-configuration/0.1.1/documentation/configuration/using-reloading-providers

Might I suggest using inotify in Linux, and perhaps the equivalent file watching methods under Windows and macOS in future updates? We already use Inotify in a home-grown library we created that is similar to swift-configuration, so it's totally possible. Example:

https://github.com/orobio/swift-configuration-reader/blob/main/Sources/ConfigurationReader/ConfigurationFileWatching/watchFile.swift

[czechboy0]

Hi @jessezamora,

yeah I'd be totally open to also watching for file changes as an optimization, but I suspect the time-based polling will always need to stay there as backup as there are some environments where I've had issues trying to watch files reliably. That's not an API-breaking change, so we can make it at any time, pre or post 1.0.

Is there an API-stable Swift library for watching files for changes you'd recommend, that works reliably on all Swift platforms? That'd likely be the first prerequisite, I'd prefer not to have to implement one from scratch in this package.

[FranzBusch]

In general, I wouldn't recommend to add a file watching based provider. File watching via APIs such as inotify is very prone to issues with the underlying file system. I have seen many problems myself already where the file system didn't send the expected notifications. I think the approach that this package took by offering providers that reload on an interval is the right one. It is very reliable and not coupled to the underlying file systems. It also produces minimal overhead and the interval can be adjusted so that configurations are updated within a reasonable amount of time.

[jessezamora]

I am not aware of any Swift library for watching files, so it may have to be either created separately or simply just implemented within this library.

@FranzBusch to your point I understand the concern, but I could see it as an option (not enabled by default) for those who want to use it and are okay with the risks. For us, we've had lots of success using inotify in Linux with no issues, but inside of a Docker container things may not work correctly from what we've seen. So, making it an optional feature still seems like a good idea.

[czechboy0]

FWIW, if the file doesn't change, the reloading provider does a single stat to detect changes. So even if you set it to 1s, I don't think it'll ever be a perf problem.