Messages in this thread | | | From | "David Schwartz" <> | Subject | RE: [Patch][RFC] epoll and half closed TCP connections | Date | Tue, 15 Jul 2003 18:46:20 -0700 |
| |
> "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
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |