lkml.org 
[lkml]   [2009]   [Dec]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe[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




\
 
 \ /
  Last update: 2009-12-19 23:59    [from the cache]
©2003-2011 Jasper Spaans