Date: Wed, 22 Oct 2003 06:02:58 -0700 (PDT) From: Matthew Jacob <mjacob@feral.com> To: Poul-Henning Kamp <phk@phk.freebsd.dk> Cc: 'Kris Kennaway' <kris@obsecurity.org> Subject: Re: Sleeping on "isp_mboxwaiting" with the followingnon-sleepablelocks held: Message-ID: <20031022055417.L93661@beppo> In-Reply-To: <17654.1066803399@critter.freebsd.dk> References: <17654.1066803399@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
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. >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20031022055417.L93661>