From owner-cvs-all@FreeBSD.ORG Fri Mar 4 18:16:10 2005 Return-Path: Delivered-To: cvs-all@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BF81B16A4D2; Fri, 4 Mar 2005 18:16:10 +0000 (GMT) Received: from mailout1.pacific.net.au (mailout1.pacific.net.au [61.8.0.84]) by mx1.FreeBSD.org (Postfix) with ESMTP id 208E443D3F; Fri, 4 Mar 2005 18:16:10 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailproxy1.pacific.net.au (mailproxy1.pacific.net.au [61.8.0.86])j24IG8A6005391; Sat, 5 Mar 2005 05:16:08 +1100 Received: from katana.zip.com.au (katana.zip.com.au [61.8.7.246]) j24IG1S5023099; Sat, 5 Mar 2005 05:16:06 +1100 Date: Sat, 5 Mar 2005 05:16:01 +1100 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: Scott Long In-Reply-To: <422891E5.3040402@samsco.org> Message-ID: <20050305045443.H18897@delplex.bde.org> References: <200503031116.22840.jhb@FreeBSD.org> <20050305032619.K18638@delplex.bde.org> <42288FA6.7010102@freebsd.org> <422891E5.3040402@samsco.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed cc: src-committers@freebsd.org cc: John Baldwin cc: cvs-src@freebsd.org cc: cvs-all@freebsd.org cc: Daniel Eischen cc: David Xu cc: Colin Percival Subject: Re: cvs commit: src/sys/kern kern_sig.c X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2005 18:16:10 -0000 On Fri, 4 Mar 2005, Scott Long wrote: > Colin Percival wrote: >> Bruce Evans wrote: >> >>> Sleeping on a stack address is just a bug [...] >> >> I was told that this was the canonical way to say "go to sleep and don't >> wake up until the timo expires" was to tsleep() with ident equal to >> something from the stack. >> >> If this isn't correct, what is the correct way to do this? I've seen >> some code which does tsleep(NULL, ... ), but I was told that was also >> wrong. > The first argument to tsleep/msleep is just a cookie that is supposed to > uniquely identify the sleeper for when you want to wake it up. Having > colliding cookies isn't terrible, but it means that the other colliding > sleepers might get woken up when they don't expect it. It might be fatal for the other sleepers, since they can legitimately assume that they never get woken up except under conditions under their control. > Using NULL is no > different than using a cookie with a very high probability of collision. Except msleep() KASSERT()s that the cookie is not null. > The suggestion to use a stack address from the local frame was made > because it gives you a fairly good chance of obtaining a unique value. > However, as Bruce points out, it's really just a side effect of the MD > stack allocation scheme, and is no way a guarantee. Using an address > from the global heap is probably a better choice, but since the stacks > are also allocated from the global heap now, there really isn't much of > a difference. Perople have pointed out that sleeping on the address of user struct was common (when there was a user struct), and sleeping on the address of a softc is a good choice for device drivers. If you don't care about uniqueness or about the exact timeout, then you can sleep on &lbolt. This would give some extra wakeups, but relatively few except for very long sleeps. The scd driver gives another example of a bad choice. It sleeps on the address of a function! This shouldn't even compile, since tsleep() takes a "void *" and function pointers are incompatible with "void *". Even when the function pointer can be converted to an object pointer without problems, its uniqueness as a cookie depends on functions being in the same address space as objects. Bruce