linux-kernel - Re[2]: epoll'ing tcp sockets for reading

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <alpine.DEB.2.00.0912191437530.4482@makko.or.mcafeemobile.com>
Date:	Sat, 19 Dec 2009 14:56:22 -0800 (PST)
From:	Davide Libenzi <davidel@...ilserver.org>
To:	Nikolai ZHUBR <zhubr@...l.ru>
cc:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
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


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/