Messages in this thread | | | Date | Sat, 19 Dec 2009 10:07:05 -0800 (PST) | From | Davide Libenzi <> | Subject | Re: epoll'ing tcp sockets for reading |
| |
On Sat, 19 Dec 2009, Nikolai ZHUBR wrote:
> Hello people, I have a question about epoll'ing tcp sockets. > > Is it possible (with epoll or some other good method) to get userspace > notified not only of the fact that some data has become available > for the socket, but also of the respective _size_ available for > reading connected with this exact event? > > Yes, read'ing until EAGAIN or using FIONREAD would provide this > sort of information, but there is a problem. In case of subsequent > continuous data arrival, an application could get stuck reading > data for one socket infinitely (after epoll return, just before > the next epoll), unless it implements some kind of artifical safety > measures.
It is up to your application to handle data arrival correctly, according to the latency/throughput constraints of your software. The "read until EAGAIN" that is cited inside the epoll man pages, does not mean that you have to exhaust the data in one single event processing loop. After you have read and processed "enough data" (where enough depends on the nature and constraints of your software), you can just drop that fd into an "hot list" and pick the timeout for your next epoll_wait() depending on the fact that such list is empty or not (you'd pick zero if not empty). Proper handling of new and hot events will ensure that no connections will be starving for service.
- Davide
| |