From owner-freebsd-bugs@FreeBSD.ORG Thu Oct 16 02:42:25 2003 Return-Path: Delivered-To: freebsd-bugs@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9AC6516A4B3 for ; Thu, 16 Oct 2003 02:42:25 -0700 (PDT) Received: from mail.cs.tu-berlin.de (mail.cs.tu-berlin.de [130.149.17.13]) by mx1.FreeBSD.org (Postfix) with ESMTP id E600143FD7 for ; Thu, 16 Oct 2003 02:42:23 -0700 (PDT) (envelope-from boris@cs.tu-berlin.de) Received: from fiesta.cs.tu-berlin.de (boris@fiesta.cs.tu-berlin.de [130.149.17.4]) by mail.cs.tu-berlin.de (8.9.3p2/8.9.3) with ESMTP id LAA17407; Thu, 16 Oct 2003 11:39:42 +0200 (MET DST) Received: (from boris@localhost)h9G9dfd2024225; Thu, 16 Oct 2003 11:39:41 +0200 (MEST) Date: Thu, 16 Oct 2003 11:39:41 +0200 From: Boris Nikolaus To: John-Mark Gurney , John Polstra , freebsd-bugs@freebsd.org Message-ID: <20031016093941.GB23308@fiesta.cs.tu-berlin.de> References: <200310130749.h9D7nWF9038579@freefall.freebsd.org> <20031013194716.GP533@funkthat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20031013194716.GP533@funkthat.com> User-Agent: Mutt/1.4.1i Subject: Re: kern/45291: kevent(2) ignores timeout if nevents == 0 X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2003 09:42:25 -0000 On Mon, Oct 13, 2003 at 12:47:16PM -0700, John-Mark Gurney wrote: > John Polstra wrote this message on Mon, Oct 13, 2003 at 09:37 -0700: > > On 13-Oct-2003 John-Mark Gurney wrote: > > > Synopsis: kevent(2) ignores timeout if nevents == 0 > > > > > > State-Changed-From-To: open->feedback > > > State-Changed-By: jmg > > > State-Changed-When: Mon Oct 13 00:46:53 PDT 2003 > > > State-Changed-Why: > > > to quote the man page: If timeout is a non-NULL pointer, it specifies > > > a maximum interval to wait for an event, > > > > > > The behavior is correct since you wanted to wait for 0 events, and since > > > it has delivered all the events it can (none), it returns. Unless provide > > > with good reason (or maybe a patch to the manpage to document this feature?) > > > I will close the PR in 5 days. I still disagree: To quote the poll and select man pages: poll: If timeout is neither zero nor INFTIM (-1), it specifies a maximum interval to wait for any file descriptor to become ready, in milliseconds. select: If timeout is a non-nil pointer, it specifies the maximum interval to wait for the selection to complete. In both cases, it is a very similar text to the kevent man page, but for poll and select, the behaviour is to wait if nfds = 0 (and so no event can be returned). > Simple fix, you wait for a single event, adding a struct kevent such as: > struct kevent ke; > ret = kevent(qfd, NULL, 0, &ke, 1, &ts); > > makes it wait the full 10 seconds. so, are you suggesting that we change > the behavior to wait for the timeout to expire before we return ANY > events? (because that is what your suggesting). Special caseing when > someone passes in 0 is not good IMO... it will probably brake lots of > code that may in advertantly set as ts, but expect immediate return > because of not specifing any return events. I think, you misunderstood me: I do not want kevent to wait for the timeout to expire before returning ANY events, I want kevent to wait for the timeout when NO event has signalled! This is not a special case, I think the current implementation handles nevent = 0 as special case, as it returns before the timeout has expired although no event has been signalled. Your fix to call kevent with nevents = 1 will remove an event from the event queue. This may be a solution for the trivial example program of the PR (as there are no events registered for the queue) but not the expected behaviour in a real main loop. To summarize, I think kevent should not return until - it has found any signalled events, or - the timeout expires, or - a (non-ignored) signal arrives as this is the behaviour of poll() and select() and IMHO the intuitive behaviour. Greetings, Boris