Date: Thu, 19 Oct 1995 11:09:50 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: hsu@cs.hut.fi (Heikki Suonsivu) Cc: taob@io.org, hsu@cs.hut.fi, freebsd-questions@freefall.freebsd.org Subject: Re: indestructible processes won't die Message-ID: <199510191809.LAA02951@phaeton.artisoft.com> In-Reply-To: <199510190540.HAA03574@shadows.cs.hut.fi> from "Heikki Suonsivu" at Oct 19, 95 07:40:23 am
next in thread | previous in thread | raw e-mail | index | archive | help
> > > 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199510191809.LAA02951>