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.
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).
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With