RE: [Patch][RFC] epoll and half closed TCP connections

["David Schwartz" <davids@webmaster.com>]

> "David Schwartz" <davids@webmaster.com> writes:

> > 	This is really just due to bad coding in 'poll', or more
> > precisely very bad
> > for this case. For example, why is it allocating a wait queue
> > buffer if the
> > odds that it will need to wait are basically zero? Why is it adding file
> > descriptors to the wait queue before it has determined that it needs to
> > wait?

> Because this is much easier to do in userspace, it's just not very
> well documented that you should almost always call poll() with a zero
> timeout first.

	It's neither easier to do nor harder, it's basically the same code in
either place. However, doing it in kernel space saves the extra user/kernel
transition, poll set allocations, and copies across the u/k boundary in the
case where we do actually need to wait.

> However it's been there for years, and things have used
> it[1].

	The thing is, for some reason it (it being the cost of calling poll with a
constant timeout for 1,024 file descriptors) is exceptionally bad on Linux.
Worse than every other OS I've tested.

> There are still optimizations that could have been done to poll() to
> speed it up but Linus has generally refused to add them.

	Yep, so we invent new APIs to fix the deficiencies in the most common API's
implementation. Whatever.

	DS