You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jun 8, 2022. It is now read-only.
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!
The text was updated successfully, but these errors were encountered:
@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.
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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!
The text was updated successfully, but these errors were encountered: