Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Sat, 19 Oct 2002 16:48:53 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Sat, 19 Oct 2002 16:48:53 -0400 Received: from sccrmhc01.attbi.com ([204.127.202.61]:44722 "EHLO sccrmhc01.attbi.com") by vger.kernel.org with ESMTP id ; Sat, 19 Oct 2002 16:48:53 -0400 Message-ID: <3DB1C9B2.3030500@kegel.com> Date: Sat, 19 Oct 2002 14:08:02 -0700 From: Dan Kegel User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020830 X-Accept-Language: de-de, en MIME-Version: 1.0 To: "Charles 'Buck' Krasic" CC: linux-kernel , linux-aio Subject: Re: epoll (was Re: [PATCH] async poll for 2.5) References: <3DB0AD79.30401@netscape.com> <20021019065916.GB17553@mark.mielke.cc> <3DB19AE6.6020703@kegel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 688 Lines: 18 Charles 'Buck' Krasic wrote: >>In summary, a short count is every bit as reliable as EAGAIN to know >>that it is safe to wait on epoll_getevents. > > Whoops. I just realized a flaw in my own argument. > > With read, a short count might precede EOF. Indeed, in that case, > calling epoll_getevents would cause the connection to get stuck. Maybe epoll should be extended with a specific EOF event. Then short reads would be fine. - Dan - 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/