The arti executable should, on Unix, honour SIGHUP, and respond by reloading the configuration.
IHNI what would the idiomatic way on Windows.
There should perhaps be other ways to achieve this too. I don't think we have anything like a control socket (and perhaps we don't want to add one). But I think that's a future thing that doesn't want to be on this milestone.
Status: I've looked at this for a bit, and I'm now presuaded that it will indeed be hairy to refactor this so as to do the right thing, without more refactoring.
What I need in particular is some kind of "application" handle to act as the receiver of new config::Config objects, and for watch_cfg to own a bit less of the reconfiguration logic. But @Diziet was right that this will probably belong as part of a larger refactoring of the arti crate.
maybe that's silly, but why not send an event on the same mpsc channel used for fs events? It will feature-creep watch_cfg a bit more, but not substantially, and would deliver a first version of the feature fairly easily I think.
I will draft an MR with what I have in mind, and if growing watch_cfg seems not worth, it can always be thrown away
I had thought about that, but what stopped me is that we would also need it to work when watch_cfg is disabled via application.watch_configuration = false. If you think it'll be reasonably clean, feel free.