Increase syscall timeouts to decrease CPU usage?

[phred]

I've been running https://github.com/azer/boxcars locally, which uses fsnotify to watch a single configuration file. Today I noticed that it's taking up 0.2% CPU even when idle, which struck me as odd.

Digging in, I found that it was due to the 100ms timeout that fsnotify uses for a timeout on the kevent() system call. As an experiment, I increased it to 1 second, and even 10 seconds. In both cases: CPU usage drops to 0%, and events still trigger as soon as the file modification happens.

Other than for tests, which should run quickly, is there any reason NOT to increase the syscall timeout? The kevent call is in a goroutine, so it doesn't matter if it's blocked. I'd rather that my programs sleep until events are ready instead of retriggering the syscall 10 times per second.

In any case, I'm keeping my local modification, as it works for me. :-) Thanks for this nice and clean little library!

[howeyc]

But if you experienced no slow down, then shouldn't the tests kick off when modifications happen as well?

I did try this, my test suite ran a lot slower.

[nathany]

@phred I've been doing some experimentation with kqueue. When using a nil timeout to block until there is an event, CPU usage is reduced to 0% while idle.