From owner-freebsd-arch@FreeBSD.ORG Thu Jan 27 02:24:14 2005 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EE21216A4CE; Thu, 27 Jan 2005 02:24:14 +0000 (GMT) Received: from mx-mtaout02.mts.net (wnpgmb02-group-smtpout.mts.net [142.161.130.102]) by mx1.FreeBSD.org (Postfix) with ESMTP id E9EC943D39; Thu, 27 Jan 2005 02:24:13 +0000 (GMT) (envelope-from modulus@wnpgmb11dc1-164-159.dynamic.mts.net) Received: from wnpgmb11dc1-164-159.dynamic.mts.net ([142.161.164.159]) by mx-mtaout02.mts.net with ESMTP <20050127022413.LAMX11399.mx-mtaout02.mts.net@wnpgmb11dc1-164-159.dynamic.mts.net>; Wed, 26 Jan 2005 20:24:13 -0600 Received: from wnpgmb11dc1-164-159.dynamic.mts.net (localhost [127.0.0.1]) j0R2Ox9Y066771; Wed, 26 Jan 2005 20:24:59 -0600 (CST) (envelope-from modulus@wnpgmb11dc1-164-159.dynamic.mts.net) Received: (from modulus@localhost)j0R2Ox2R066770; Wed, 26 Jan 2005 20:24:59 -0600 (CST) (envelope-from modulus) Date: Wed, 26 Jan 2005 20:24:59 -0600 From: "Christian S.J. Peron" To: David Xu Message-ID: <20050127022459.GA63961@wnpgmb11dc1-164-159.dynamic.mts.net> References: <20050127012401.GB48521@freefall.freebsd.org> <41F84C25.60903@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <41F84C25.60903@freebsd.org> User-Agent: Mutt/1.4.2.1i cc: arch@freebsd.org Subject: Re: resolver un-conditionally restarts interrupted kevent X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2005 02:24:15 -0000 On Thu, Jan 27, 2005 at 10:04:21AM +0800, David Xu wrote: > Because they can not be simply restarted. those interfaces > have in/out parameters which may already be changed by kernel > before returning, also a timeout wait can not be restarted, you > told kernel to sleep 10 minutes, and at minute 9, it gets a signal > and is restarted, it will return to user code after totally 19 > minutes. Ok, that makes sense > > > 2) why do we unconditionally restart kevent in our > > resolver code? > > > I think that's right because the code checks 'n < 0' first, > it got nothing and does timeout calculation by itself, that's OK. The problem is this breaks many programs which use loops and conditions for program termination. Some examples are ping(8) and tcpdump(1). I.E. you go to ping some host or process some packets without -n and try to ctrl+c to interrupt the process, the program will not terminate because the resolver keeps restarting the kevent system call. Does anyone think it would make sense to not un-conditionally restart the system call and have EINTR (or something to this effect) propogate back to the process through h_errno? -- Christian S.J. Peron csjp@FreeBSD.ORG FreeBSD Committer