Date: Fri, 15 Apr 2005 17:55:33 +0200 From: Joerg Sonnenberger <joerg@britannica.bec.de> To: freebsd-hackers@freebsd.org Subject: Re: MDELAY() Message-ID: <20050415155533.GA3652@britannica.bec.de> In-Reply-To: <200504160112.49813.doconnor@gsoft.com.au> References: <200504151303.j3FD3Bhv073436@marlena.vvi.at> <20050415150408.GA1442@britannica.bec.de> <200504160112.49813.doconnor@gsoft.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050415155533.GA3652>