I assume that “how epoll works” you refer to how it works from the point of view of the user (how, how your code receives the notification and should process it), unlike the point of view of the kernel (how the way epoll is implemented) .
The short version is very simple: it is just like poll , with the exception of two things:
- It uses a handle to an opaque data structure, so you don't pass as much data back and forth along the kernel boundary.
- It has parameters that
poll does not have (in particular, trigger and one-time notifications) that can allow you to write more efficient code in certain situations.
(There is also the fact that it only works with linux. BSD and related systems have kqueue , a significantly different way to get some of the same benefits, Solaris has /dev/poll , etc., and some * nixes have nothing therefore, if you want to write portable code, you either need to use poll , or use some higher-level library like libevent , or write the libevent equivalent libevent .)
If you already understand select and poll , the Wikipedia article and the blog post linked in your links should tell you almost everything you need to know between them, and the man page will fill in any gaps.
If not, first learn about poll , and only then will it make sense to find out how epoll differs.
I'm still not sure how this relates to your main question. You can epoll a inotify in the database file or the pipe or socket underlying the messaging system, or just something else that can be represented as a file descriptor in Linux, so I'm not sure how understanding epoll will help you explain the differences between polling the database and polling the message queue. Of course, there are big differences between them, but the mechanism for triggering events is not one of them.