What's the advantage of using epoll_create1() instead of epoll_create()

noisebleed picture noisebleed · Apr 4, 2012 · Viewed 7.1k times · Source

I'm rewriting a multithread Linux-2.6.32+ application to replace select with epoll.

The man pages for epoll_create1(2) declare that:

If flags is 0, then, other than the fact that the obsolete size argument is dropped, epoll_create1() is the same as epoll_create().

Yet, isn't this obsolete size argument used in epoll_wait(2) as maxevents?

epoll_wait(int epfd, struct epoll_event *events,
                  int maxevents, int timeout);

This means when using epoll we can avoid declaring the maximum number of events in epoll_create1 but sooner or later we have to reference it when calling epoll_wait? If so, what's the point of bringing epoll_create1 into the game?

Thanks for enlighten me on this subject.

Answer

paxdiablo picture paxdiablo · Apr 4, 2012

With epoll_wait(), maxevents tells you you maximum number of events that will be returned to you. It has nothing to do with how many are maintained within the kernel.

Older versions of epoll_create() used the size to set certain limits but that's no longer done, hence the comment that the size argument is obsolete. This is made evident by the source code (in fs/eventpoll.c as at the time of this answer):

SYSCALL_DEFINE1(epoll_create1, int, flags) {
    return do_epoll_create(flags);
}
SYSCALL_DEFINE1(epoll_create, int, size) {
    if (size <= 0) return -EINVAL;
    return do_epoll_create(0);
}

You can see that they're almost identical except that:

  • epoll_create1() accepts flags, passing them on to do_epoll_create();
  • epoll_create() accepts size, checking it, but otherwise ignoring it;
  • epoll_create() passes default flags (none) to do_epoll_create().

Hence the advantage of using epoll_create1() is that it allows you to specify the flags, which I think are currently limited to close-on-exec (so that the file descriptor is automatically closed when exec-ing another program).