From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jamie Lokier Subject: Re: Bug: epoll_wait timeout is shorter than requested Date: Mon, 17 Jan 2005 14:43:33 +0000 Message-ID: <20050117144333.GB23427@mail.shareable.org> References: <87651wl32d.fsf@qrnik.zagroda> <20050117114821.GB20152@mail.shareable.org> <87r7kk41gp.fsf@qrnik.zagroda> <20050117143348.GA23427@mail.shareable.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Received: from mail.shareable.org ([81.29.64.88]:39863 "EHLO mail.shareable.org") by vger.kernel.org with ESMTP id S262811AbVAQOnf (ORCPT ); Mon, 17 Jan 2005 09:43:35 -0500 Received: from mail.shareable.org (localhost [127.0.0.1]) by mail.shareable.org (8.12.8/8.12.8) with ESMTP id j0HEhX81023933 for ; Mon, 17 Jan 2005 14:43:33 GMT Received: (from jamie@localhost) by mail.shareable.org (8.12.8/8.12.8/Submit) id j0HEhXE7023931 for linux-fsdevel@vger.kernel.org; Mon, 17 Jan 2005 14:43:33 GMT To: linux-fsdevel@vger.kernel.org Content-Disposition: inline In-Reply-To: <20050117143348.GA23427@mail.shareable.org> Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org Jamie Lokier wrote: > > Well, if the kernel measured the delay more accurately than to a clock > > tick, it could notice that a requested 1ms would be satisifed by, say, > > 8ms which remained from the current tick. > > I agree 100%! That's a good solution. > > If select/poll/epoll were implemented by the kernel reading the > current time accurately before deciding how many ticks to wait for, > they could satisfy SUSv3's constraint, _and_ allow the useful > behaviour of application events at the tick rate, _and_ reduce the > number of system calls in some programs which call select(). > > If you want to change the code in fs/select.c and fs/eventpoll.c to do > this, please do so; I'll be happy to support the case for it. That said, _any_ change to select/poll is sure to break some programs, which depend on the current quirks. By the way, the most logically useful interface would take an *absolute* end time, in any of the forms that the POSIX timer code allows. This is because nearly every application which calls select/poll/epoll with a timeout first calls gettimeofday() and then computes the difference between an absolute time and the current clock time to pass as the timeout argument - introducing a race condition in the process. Giving an absolute time would eliminate the race condition _and_ all calls to the microsecond timer, which is often quite slow. However, that would require adding yet another non-standard interface. Perhaps a case can be made for epoll_wait_abstime or something like that, seeing as epoll is quite non-standard anyway. -- Jamie