Trouble killing processes in SysV/AT

Greg Limes limes at sun.uucp
Sat Apr 30 16:17:17 AEST 1988


In article <625 at vsi.UUCP> friedl at 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 at sun.com]				frames to /dev/fb



More information about the Comp.unix.microport mailing list