Xref: utzoo comp.unix.questions:6814 comp.unix.wizards:8189 comp.unix.microport:573
Path: utzoo!mnetor!uunet!littlei!vrs
From: vrs@littlei.UUCP (vrs)
Newsgroups: comp.unix.questions,comp.unix.wizards,comp.unix.microport
Subject: Re: Trouble killing processes in SysV/AT
Message-ID: <270@gandalf.littlei.UUCP>
Date: 2 May 88 06:59:05 GMT
References: <3950@killer.UUCP> <3951@killer.UUCP> <3967@killer.UUCP> <9233@sol.ARPA>
Reply-To: vrs@vrs.UUCP (Vincent R. Slyngstad)
Organization: Intel Corp., OMSO UNIX Development, Hillsboro, OR
Lines: 22

In article <9233@sol.ARPA> jpayne@cs.rochester.edu (Jonathan Payne) 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?
>>> 
>
>I believe the story goes something like this.  The process is sleeping at
>a priority that is too high (or low) to be interrupted by a software
>interrupt.  That is, while in kernel mode the process did a sleep(chan1,
>PRI), but nothing has come along to wake it up (with wakeup(chan1)).

This is nearly always because a device wants to write output and the connection
has been lost.  The driver fails to flush pending output (and/or new output)
after the connection goes down.

There is another scenario worth worrying about during driver design:  even
if the driver sleeps at a low priority (as it does in the usual tty line
discipline), a kill will cause the process to try to exit().  The exit()
will mask off all signals and close all files.  When it closes the device
with the lost connection, it sleeps AGAIN, this time with signals ignored.

We've done a fair bit of work on our Multibus drivers since XENIX 3.4 :-).