Messages in this thread | | | Date | Sat, 19 Dec 2009 14:56:22 -0800 (PST) | From | Davide Libenzi <> | Subject | Re[2]: epoll'ing tcp sockets for reading |
| |
On Sun, 20 Dec 2009, Nikolai ZHUBR wrote:
> > 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. > > Well, no doubt, terrible starvation can be avoided this way, ok. > However doesn't this look like userspace code is forced to make decisions > (when to pause reading new data and proceed to other sockets etc.) based on > some rather abstract/imprecise/overcomplicated assumptions and/or with > the help of additional syscalls, while a simple and reasonable hint for > such a decision being wasted somewhere on the way from kernelspace to > userspace?
The kernel cannot make decisions based on something whose knowledge is userspace bound. What you define as "abstract/imprecise/overcomplicated" are simply decisions that you, as implementor of the upper layer protocol, have to take in order to implement your userspace code. And I, personally, see nothing even close to be defined complicated in such code. Whenever you're asking for an abstraction/API to implement a kind of software which exist in large quantities on a system, you've got to ask yourself how relevant such abstraction is at the end, if all the existing software have done w/out it.
- Davide
| |