Xref: utzoo comp.unix.questions:6788 comp.unix.wizards:8154 comp.unix.microport:562
Path: utzoo!mnetor!uunet!seismo!sundc!pitstop!sun!limes
From: limes@sun.uucp (Greg Limes)
Newsgroups: comp.unix.questions,comp.unix.wizards,comp.unix.microport
Subject: Re: Trouble killing processes in SysV/AT
Message-ID: <51444@sun.uucp>
Date: 30 Apr 88 06:17:17 GMT
References: <3950@killer.UUCP> <3951@killer.UUCP> <468@micropen> <625@vsi.UUCP>
Reply-To: limes@sun.UUCP (Greg Limes)
Organization: Sun Microsystems, Mountain View
Lines: 40

In article <625@vsi.UUCP> friedl@vsi.UUCP (Stephen J. Friedl) writes:
>
>     I would be interested to hear from driver writers who are
>more familiar with this: how does one determine whether a sleep
>should be interruptible or not?  Why aren't they all this way
>(not a plea, just a question)?  

Sometimes you sleep in places where it is difficult (or impossible) to
clean up after an abort. You previously verified that the controller is
out there, dammit, and it is *going* to respond, and there is just too
much to clean up in an abort, or there is no way to abort the controller,
or maybe you just do not want to spend the time to make abort work in
*this* instance which is (grin) never going to happen anyway ... well,
you get the picture. Sometimes it is just laziness.

>                               The cartridge tape driver on the
>3B2 obviously runs at a noninterruptible priority because once I
>type a command that deals with it I sometimes have to wait for
>the retension pass (usually a couple of  minutes) before the
>interrupt is honored :-(.

Worse yet, on some SCSI-based systems, when the tape drive starts
rewinding, the SCSI bus is locked until the operation completes. Kind of
messy when your swap disk is out there on the SCSI.

>     A side note: WCHAN is a "wait channel", the address on which
>the sleep() awaits awakenment (I just made that word up), and it is
>found by the "-l" option to ls.  If you are really industrious,
>you can write a program that looks this address up in the /unix
>namelist and gives a clue for what the process is waiting.  You
>can't always nail it down, as you really need source to get
>structure offsets and stuff, but it is instructive to get a clue
>whether a program is waiting on disk or a tty or whatever.

some versions of "ps" do this lookup for you ... at least, SunOS 4.0
does now. shocked the heck out of me the first time the WCHANS started
coming up "socket", "pause", "select", and so on. Seems nowadays that
most everything sleeps on "select" on my workstation.
-- 
   Greg Limes [limes@sun.com]				frames to /dev/fb