Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S269641AbTGOUPJ (ORCPT ); Tue, 15 Jul 2003 16:15:09 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S269645AbTGOUPJ (ORCPT ); Tue, 15 Jul 2003 16:15:09 -0400 Received: from code.and.org ([63.113.167.33]:29902 "EHLO mail.and.org") by vger.kernel.org with ESMTP id S269641AbTGOUPG (ORCPT ); Tue, 15 Jul 2003 16:15:06 -0400 To: "David Schwartz" Cc: "Davide Libenzi" , "Eric Varsanyi" , "Linux Kernel Mailing List" Subject: Re: [Patch][RFC] epoll and half closed TCP connections References: From: James Antill Content-Type: text/plain; charset=US-ASCII Date: 15 Jul 2003 16:27:56 -0400 In-Reply-To: Message-ID: User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Honest Recruiter) MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1065 Lines: 22 "David Schwartz" 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. However it's been there for years, and things have used it[1]. There are still optimizations that could have been done to poll() to speed it up but Linus has generally refused to add them. [1] http://www.and.org/socket_poll/ -- # James Antill -- james@and.org :0: * ^From: .*james@and\.org /dev/null - 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/