Xref: utzoo comp.unix.questions:6779 comp.unix.wizards:8146 comp.unix.microport:560
Path: utzoo!mnetor!uunet!vsi!friedl
From: friedl@vsi.UUCP (Stephen J. Friedl)
Newsgroups: comp.unix.questions,comp.unix.wizards,comp.unix.microport
Subject: Re: Trouble killing processes in SysV/AT
Message-ID: <625@vsi.UUCP>
Date: 30 Apr 88 03:37:17 GMT
References: <3950@killer.UUCP> <3951@killer.UUCP> <468@micropen>
Organization: V-Systems, Inc. -- Santa Ana, CA
Lines: 65
Summary: kernel sleep() priorities

In article <468@micropen>, dave@micropen (David F. Carlson) writes:
< In article <3951@killer.UUCP>, wnp@killer.UUCP (Wolf Paul) writes:
< > Can anyone enlighten me as to what causes a process to become "immortal"
< > in System VR2,  or Microport UNIX System V/AT, to be more specific?
< > 
< This "problem" is not a Microport issue at all: it is UNIX all the way.
< 
< The quick answer is that any process that is in the kernel with a WCHAN
< will not go back to user mode until that channel is awoken.  Who will
< awaken it?  Two choices:  a device driver interrupt or a kernel timer
< interrupt.  In all likelihood your ill-behaved process is waiting in
< a poorly written device driver close().

     There is a third choice.  When a driver calls sleep(), one
of the arguments is a sleeping priority.  In addition to entering
into scheduling considerations, it determines whether or not the
sleep() can be interrupted by a signal.  If this priority is less
than or equal to PZERO (defined in <sys/param.h>), then the
driver can't be interrupted, with the converse being true.

     Different drivers use different priorities.  Example from
the 3B2, where PZERO is 25.  In the tty driver, an open(2) on a
port will block until the carrier detect line is seen by the
hardware.  When the process sleeps on this, its priority is
TTOPRI.  Since TTOPRI is #defined in <sys/tty.h> as 29, this call
is interruptible.

     To demonstrate this, find a port (say, tty11) that has no
cables or processes attached to it.  Assuming you have read
permissions, cat the device and hit DELETE:

        # cat < /dev/tty11
        (hit DELETE)
        /dev/tty11: cannot open
        #

     Because TTOPRI > PZERO, your interrupt is heeded.

     Alas, this is not always the case.  In the floppy block
device open() handler, it sleeps with PRIBIO (#defined in
<sys/param.h> to be 20).  When you try to (say) mount the floppy,
you have to wait for it to succeed or timeout; your interrupt is
ignored because PRIBIO < PZERO.

     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)?  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 :-(.

     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.

-- 
Steve Friedl      V-Systems, Inc. (714) 545-6442   Resident 3B2 hacker
friedl@vsi.com      {backbones}!vsi.com!friedl      attmail!vsi!friedl