Why does Linux treat accept() as read() operation in certain cases?

Suppose we have a socket server in C that is implemented using polling methods such as poll() or epoll(). And suppose the later is used (the same goes for poll()).

In any of the existing such servers, including the example in the epoll() man page, the accept() is called on listener whenever EPOLLIN event occurs. And it works. Which means that EPOLLIN event is triggered when the server has a pending connection to accept. However, the man page definition of the EPOLLIN event says:

EPOLLIN
The associated file is available for read(2) operations.

MEDevel.com: Open-source for Healthcare and Education

Collecting and validating open-source software for healthcare, education, enterprise, development, medical imaging, medical records, and digital pathology.

Visit Medevel

This implies that EPOLLIN is an event specifically for read() operations.

Why can it be used for accept()? I went through all the relevant man pages and nowhere it is specified that accept() is treated as read() inside polling mechanisms. Yet is does work like that.

>Solution :

This is explained in the documentation of accept(2):

In order to be notified of incoming connections on a socket, you
can use select(2), poll(2), or epoll(7). A readable event will
be delivered when a new connection is attempted and you may then
call accept() to get a socket for that connection.
Alternatively, you can set the socket to deliver SIGIO when
activity occurs on a socket; see socket(7) for details.