From owner-freebsd-questions Thu Oct 19 11:16:46 1995 Return-Path: owner-questions Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id LAA26922 for questions-outgoing; Thu, 19 Oct 1995 11:16:46 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id LAA26917 for ; Thu, 19 Oct 1995 11:16:43 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id LAA02951; Thu, 19 Oct 1995 11:09:56 -0700 From: Terry Lambert Message-Id: <199510191809.LAA02951@phaeton.artisoft.com> Subject: Re: indestructible processes won't die To: hsu@cs.hut.fi (Heikki Suonsivu) Date: Thu, 19 Oct 1995 11:09:50 -0700 (MST) Cc: taob@io.org, hsu@cs.hut.fi, freebsd-questions@freefall.freebsd.org In-Reply-To: <199510190540.HAA03574@shadows.cs.hut.fi> from "Heikki Suonsivu" at Oct 19, 95 07:40:23 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1426 Sender: owner-questions@FreeBSD.org Precedence: bulk > > > trying to output something somewhere, the output is lost or something > > > else is done with it, but the process is killed. That is the whole > > > meaning of SIGKILL, isn't it, to kill, with no excuses? > > > > And if the process is in disk wait? > > I can't see any reason why there should be a possibility of unkillable > processes in a system, no matter what IO it happens to be doing when it > gets SIGKILL? You'd have to be able to back out specific long delay operations by process ID. Consider the case of multiple sleepers on a single address of a long delay operation, one of which you want to kill (and thus "wakeup" to take the kill) and one of which you don't. This actually means the flush "soloution" is bogus. The problem is in the state transitions being unidirectional: there are some operations which must run to completion by virtue of the structure used to implement them. You have to transit several states A->B->C->D to get to a point where the state is determinate and the operation can be backed out. If you block in A->B or B->C, for instance, there is no way to recover state. That all said, there are some places where it's not really required by the design, only by the implementation. CTS/RTS on serial ports is one good example. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.