More robust logic for gokrazy.WaitForClock about gokrazy

[stapelberg]

I agree that the current logic is lacking.

With regards to notification mechanisms, I find the solutions currently brought up to either seem unclean (magic files in /tmp) or too complex (custom message bus).

I’m tempted to just keep the current logic, but extend the check to 1 year instead of 1 minute. If users don’t care about their appliance not working for a year, we can safely assume the data isn’t important anyway and corruption is okay. Also, regular software updates should happen more frequently than 1 year.

The 1 year change seems like the simplest solution to me, both because it requires only minimal changes and notably because it doesn’t introduce any new concepts. If we end up with a notification mechanism/message bus at some point, we can always revisit.

Does that sound reasonable?

BTW, the DHCP client currently sends a SIGHUP to init once it acquires a lease, which will then update its listeners if necessary. This is obviously a one-off solution which doesn’t extend to client applications. Thinking about it, DHCP is far from the only way to configure addresses, though: IPv6 autoconf may result in new addresses, and e.g. hot-plugging USB ethernet adapters even more so. Hence, applications which are interested in offering more specific listeners than wildcard listeners (e.g. :80) should monitor network addresses anyway.

Currently, I’m inclined to try to have applications blackbox-monitor the resource in question (e.g. time, network addresses). gokrazy can provide helpers for things which turn out to be common, such as the WaitForClock one we already have. Adding one for network addresses and making init use it would be a welcome improvement.