Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Sat, 19 Oct 2002 13:29:19 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Sat, 19 Oct 2002 13:29:19 -0400 Received: from sccrmhc01.attbi.com ([204.127.202.61]:12517 "EHLO sccrmhc01.attbi.com") by vger.kernel.org with ESMTP id ; Sat, 19 Oct 2002 13:29:17 -0400 Message-ID: <3DB19AE6.6020703@kegel.com> Date: Sat, 19 Oct 2002 10:48:22 -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: Mark Mielke CC: John Myers , Davide Libenzi , Benjamin LaHaise , Shailabh Nagar , linux-kernel , linux-aio , Andrew Morton , David Miller , Linus Torvalds , Stephen Tweedie Subject: Re: epoll (was Re: [PATCH] async poll for 2.5) References: <3DB0AD79.30401@netscape.com> <20021019065916.GB17553@mark.mielke.cc> 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: 1621 Lines: 38 Mark Mielke wrote: > On Fri, Oct 18, 2002 at 05:55:21PM -0700, John Myers wrote: > >>So whether or not a proposed set of epoll semantics is consistent with >>your Platonic ideal of "use the fd until EAGAIN" is simply not an issue. >>What matters is what works best in practice. > > >>From this side of the fence: One vote for "use the fd until EAGAIN" being > flawed. If I wanted a method of monopolizing the event loop with real time > priorities, I would implement real time priorities within the event loop. The choice I see is between: 1. re-arming the one-shot notification when the user gets EAGAIN 2. re-arming the one-shot notification when the user reads all the data that was waiting (such that the very next read would return EGAIN). #1 is what Davide wants; I think John and Mark are arguing for #2. I suspect that Davide would be happy with #2, but advises programmers to read until EGAIN anyway just to make things clear. If the programmer is smart enough to figure out how to do that without hitting EAGAIN, that's fine. Essentially, if he tries to get away without getting an EAGAIN, and his program stalls because he didn't read all the data that's available and thereby doesn't reset the one-shot readiness event, it's his own damn fault, and he should go back to using level-triggered techniques like classical poll() or blocking i/o. - 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/