Re: Sleeping on "isp_mboxwaiting" with the followingnon-sleepablelocks held:

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_at_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_at_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.
>