networking with epoll: error handling

Question

I am working on a networking application, written in C, using the Linux epoll facility. I am indeed implementing my own event loop, and yes, I know there are libraries that do this for me. This is just an exercise, however, and I _want_ to implement the event loop myself.

I was wondering about how to tackle error handling, specifically handling errors returned by epoll system calls. Should I really check for each return value? Because, it seems to me that some of the errors returned by eg epoll_ctl are logic errors rather than runtime errors ; I mean, the only time I saw epoll_ctl fail was when I accidentally fed it an illegal epoll file descriptor or something else that only occurs when you write incorrect code. So my question is, can epoll_ctl actually return a 'runtime error', like, say, write does when a pipe is broken? If so, is it something I should check for? I do not intend to check for errors that indicate the kernel has run out of resources or stuff like that (in that case, what could one even do?). Additional question: can fcntl produce a runtime error of some sort when it is only used to set some flags ( O_NONBLOCK )?

Answer 1

Yes, epoll can return a runtime error.

From the manpage:

ERRORS

EBADF epfd or fd is not a valid file descriptor.

EEXIST op was EPOLL_CTL_ADD , and the supplied file descriptor fd is already registered with this epoll instance.

EINVAL epfd is not an epoll file descriptor, or fd is the same as epfd , or the requested operation op is not supported by this interface.

ENOENT op was EPOLL_CTL_MOD or EPOLL_CTL_DEL , and fd is not registered with this epoll instance.

ENOMEM There was insufficient memory to handle the requested op control operation.

ENOSPC The limit imposed by /proc/sys/fs/epoll/max_user_watches was encountered while trying to register ( EPOLL_CTL_ADD ) a new file descriptor on an epoll instance. See epoll (7) for further details.

EPERM The target file fd does not support epoll .

As you can see, ENOMEM and ENOSPC are runtime errors. Depending on your logic, EPERM might also be a runtime error (eg if you are incorporating stdin into epoll and there is a redirect).

However, good practice suggests you check anyway - far better to fail early if you have a logic error.