Every Watcher instance does unix.EpollWait in a loop inside a goroutine. Since this is direct syscall, which circumvents Go runtime poller, it wastes entire OS thread. If you create N watchers, N OS threads will be doing nothing except waiting in epoll_wait syscall.
This can be theoretically fixed, because both inotify fd and even epoll fd are pollable.
There's even convenient method in internal/poll (https://golang.org/pkg/internal/poll/#FD.RawRead) which does what we want. However, internal packages are not acessible from third-party code.
I'm not sure it's even fixable in current Go. There're many related issues in the Go bug tracker which are not yet resolved (probably not a complete list): golang/go#15021 golang/go#24331 golang/go#22939
Every
Watcherinstance doesunix.EpollWaitin a loop inside a goroutine. Since this is direct syscall, which circumvents Go runtime poller, it wastes entire OS thread. If you createNwatchers,NOS threads will be doing nothing except waiting inepoll_waitsyscall.This can be theoretically fixed, because both inotify fd and even epoll fd are pollable.
There's even convenient method in
internal/poll(https://golang.org/pkg/internal/poll/#FD.RawRead) which does what we want. However, internal packages are not acessible from third-party code.I'm not sure it's even fixable in current Go. There're many related issues in the Go bug tracker which are not yet resolved (probably not a complete list): golang/go#15021 golang/go#24331 golang/go#22939