documentation: not obvious what the API on watcher.Errors is

[stevekuznetsov]

When I set up a watch, the examples quickly set up an infinite loop over the two channels:

go func() {
    for {
        select {
        case event := <-watcher.Events:
            // handle event
        case err := <-watcher.Errors:
            // handle error
        }
    }
}()

However, it is not really clear to me what types of errors can occur and if any of them invalidate the watch entirely. What is the appropriate means of handling errors? Is there a typedef for all the types of errors possible?

[stevekuznetsov]

Looks like ( on Linux, anyway ) the errors will be those from epoll_wait, so the following could be possible:

       EBADF  epfd is not a valid file descriptor.

       EFAULT The memory area pointed to by events is not accessible with
              write permissions.

       EINTR  The call was interrupted by a signal handler before either (1)
              any of the requested events occurred or (2) the timeout
              expired; see signal(7).

       EINVAL epfd is not an epoll file descriptor, or maxevents is less
              than or equal to zero.

I would expect EBADF to be exposed in the fsnotify.Watcher#Add() call, the runtime should ensure EFAULT doesn't occur, EINTR will kill the whole process (??) and EINVAL would invalidate the watch?

[ijc]

In the context of reason (1) in the description quoted above EINTR is just what you get if some signal was delivered to the process, it doesn't kill the process (the signal itself might, but many wont and that is somewhat unrelated with getting EINTR). The EINTR is just a side effect of needing to bounce the process out of the kernel in order to deliver the signal. The right response in general (assuming there is some way to distinguish from case (2) above and this isn't in an event loop with other work to do) is for the runtime to just reenter the syscall.