From owner-freebsd-hackers@FreeBSD.ORG Fri Apr 15 15:55:37 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D156716A4CE for ; Fri, 15 Apr 2005 15:55:37 +0000 (GMT) Received: from hydra.bec.de (www.ostsee-abc.de [62.206.222.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4971643D45 for ; Fri, 15 Apr 2005 15:55:37 +0000 (GMT) (envelope-from joerg@britannica.bec.de) Received: from britannica.bec.de (unknown [139.30.252.72]) by hydra.bec.de (Postfix) with ESMTP id 2F2DB35707 for ; Fri, 15 Apr 2005 17:55:36 +0200 (CEST) Received: by britannica.bec.de (Postfix, from userid 1001) id 01CDE7D02; Fri, 15 Apr 2005 17:55:33 +0200 (CEST) Date: Fri, 15 Apr 2005 17:55:33 +0200 From: Joerg Sonnenberger To: freebsd-hackers@freebsd.org Message-ID: <20050415155533.GA3652@britannica.bec.de> Mail-Followup-To: freebsd-hackers@freebsd.org References: <200504151303.j3FD3Bhv073436@marlena.vvi.at> <20050415150408.GA1442@britannica.bec.de> <200504160112.49813.doconnor@gsoft.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200504160112.49813.doconnor@gsoft.com.au> User-Agent: Mutt/1.5.9i Subject: Re: MDELAY() X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2005 15:55:37 -0000 On Sat, Apr 16, 2005 at 01:12:42AM +0930, Daniel O'Connor wrote: > On Sat, 16 Apr 2005 00:34, Joerg Sonnenberger wrote: > > > You may want to check out timeout(9) / untimeout(9), see man 9 timeout > > > for details. > > > > You should not use timeout(9) without a very good reason, the callout_* > > interface is prefered. > > Can someone add a warning to the top of the makefile similar to the one for > spl? It's not that bad, timeout(9) has a few cases, where replacing it involves work. I've done that in DragonFly, I know what I'm talking about. The reason for this advice is that the timeout(9) API has two major short comings: (a) It depends on some internal magic to provide the storage, but doesn't have a clear way to handle errors. The storage space can be a few hundred KB of kernel memory mostly wasted. (b) It is difficult to cancel all outstanding timers correctly because the race conditions are difficult to avoid when calling untimeout. Since (b) is pretty much a requirement for the kernel nowaday and you have to keep track of the return value anyway, you can almost mechanically convert such code to the callout_* interface. That also avoids (a). Concerning your original question about the inefficiency of DELAY, what timeouts are we talking about? For anything in the area of a few micro seconds, DELAY is most likely better, because it avoids context switches and the associated cache pollution. Joerg