Drag up the poller interval for a blocking read.
Drag up the poller interval for a blocking read.

Originally, I wanted to set this at a tiny number, so that if one was following it from the outside and attaching timestamps there, it would be pretty dang accurate.  But that's... not very useful, not very accurate anyway (given that we support late joins), and just generally seeming pretty suspect at this point.

Raising the stall interval from 1ms to 20ms makes it significantly less egregious on CPU usage, without feeling too onerous (even in twerk).  Other systems -- https://github.com/docker/docker/blob/2a540c18b69bebd7153ba87ffc91aade95ba2769/pkg/filenotify/poller.go#L23 -- have gone as high as 200ms without apparent user complaint, though I think that's rather high.

This really should consider breaking down and using inotify of some kind, but I'm less than thrilled with the packages I've looked at so far.  Getting it cross OS is a nice idea, but drags in a surprisingly large amount of code; and some of the best looking contenders for some bizzarotron reason decided they're just not going to support a seamless polling interface as a fallback, which is... really... just, why.  It's *really* not uncommon to hit user inotify limits in my experience; not having a fallback on linux is just bonko.

It's also worth mentioning that this poller is probably going to be more efficient than a generic inotify replacement anyway, since all we really care about is advancing a read mark.  Stat syscalls to detect other changes and then triggering reads isn't going to be a big win, unless stat calls are significantly cheaper than empty/EOF reads for some reason.

So.  Incremental step.  Other notify options can be reviewed again in the future; I'm sporting a pretty large headache fueled by disappointment in the state of computing circa 2016.

Signed-off-by: Eric Myhre <2346ad27d7568ba9896f1b7da6b5991251debdf2@exultant.us>

polydawn/repeatr,subuser-security/repeatr,subuser-security/repeatr,polydawn/repeatr