From owner-freebsd-current@FreeBSD.ORG Wed Oct 22 06:03:01 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3454316A4B3; Wed, 22 Oct 2003 06:03:01 -0700 (PDT) Received: from beppo.feral.com (beppo.feral.com [192.67.166.79]) by mx1.FreeBSD.org (Postfix) with ESMTP id 858E543FBD; Wed, 22 Oct 2003 06:03:00 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from localhost (mjacob@localhost [127.0.0.1]) by beppo.feral.com (8.12.9p1/8.12.9) with ESMTP id h9MD2wSo093709; Wed, 22 Oct 2003 06:02:59 -0700 (PDT) (envelope-from mjacob@feral.com) Date: Wed, 22 Oct 2003 06:02:58 -0700 (PDT) From: Matthew Jacob X-X-Sender: mjacob@beppo To: Poul-Henning Kamp In-Reply-To: <17654.1066803399@critter.freebsd.dk> Message-ID: <20031022055417.L93661@beppo> References: <17654.1066803399@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: alpha@freebsd.org cc: current@freebsd.org cc: 'Kris Kennaway' Subject: Re: Sleeping on "isp_mboxwaiting" with the followingnon-sleepablelocks held: X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: mjacob@feral.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Oct 2003 13:03:01 -0000 It isn't the "cannot sleep from geometry calls" that is twitting me a bit, it's the "I cannot tell at my call depth in the stack whether some dork above can't tolerate a sleep[1]". If I've missed some usage point with the SMP stuff that I *can* tell this with ease, enlighten me. -matt [1]: by 'sleep', I mean if I do *my* locking right, I should be able to yield the processor and wait for an event (an interrupt in this case). A yield might not actually do anything but call idle- if that's what is appropriate. There are several things meant by "cannot sleep"- one is deadlock avoidance and the other is thread of execution ordering. A blanket "cannot sleep" sometimes can mean just plain poor design. I don't really mean to be inflammatory here but I kinda *am* raising my eyebrows here with a polite query of "are you sure you really want to do this this way?". I mean, this particular instance isn't a big deal. Instead of waiting for a mailbox event to clear I'll poll it, doing nothing useful otherwise. It's a rare event, but it makes the system sluggish. There are alternative designs that I could take at this level that would do neither, but add greatly to code complexity at this level. No big deal, but still... On Wed, 22 Oct 2003, Poul-Henning Kamp wrote: > In message <000001c3981c$49fc17b0$23a610ac@win2k>, "Matthew Jacob" writes: > > >Well, I don't agree with the design here, but it is what it is. I'll > >make the change that you've added a requirement for. > > This is nothing new, but it is new that we can and do enforce it. > > -- > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > phk@FreeBSD.ORG | TCP/IP since RFC 956 > FreeBSD committer | BSD since 4.3-tahoe > Never attribute to malice what can adequately be explained by incompetence. >