Date: Mon, 28 Aug 2006 13:23:30 +0000 (GMT) From: Michael Abbott <michael@araneidae.co.uk> To: Oliver Fromme <olli@lurza.secnetix.de> Cc: freebsd-stable@FreeBSD.ORG Subject: Re: NFS locking: lockf freezes (rpc.lockd problem?) Message-ID: <20060828124935.G62656@saturn.araneidae.co.uk> In-Reply-To: <200608281220.k7SCKoJW054182@lurza.secnetix.de> References: <200608281220.k7SCKoJW054182@lurza.secnetix.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 28 Aug 2006, Oliver Fromme wrote:
> SIGKILL _does_ always work. However, signal processing can be delayed
> for various reasons.
[...]
> Well, in theory, a special case could be made for SIGKILL, but it's
> quite difficult if you don't want break existing semantics (or creating
> holes).
Thank you, that was both instructive and interesting.
> if a process is stopped (SIGSTOP), further signals will only take effect
> when it continues (SIGCONT).
Um. Doesn't this mean that SIGCONT is already a special case?
I think there is a case to be made for special casing SIGKILL, but in a
sense it's not so much the fate of the process receiving the SIGKILL that
counts: after all, having sent -9 I know that it will never process again.
More to the point, all processes which are waiting for the killed process
should be released. I think maybe I'd like to change the process into Z
('zombie') state while it's still blocked in IO! Sounds like a new state
to me, actually: K, "killed in disk wait".
Of course, ideally, all other resources held by the new zombie should also
be released ... including the return context for the blocked IO call!
Tricky, but the process is never going to use its resources again. Of
course, any resources held in the blocked IO call itself are another
matter...
Ah well. I guess it's a bit of an academic point.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060828124935.G62656>