From owner-freebsd-stable@FreeBSD.ORG Mon Aug 28 13:23:33 2006 Return-Path: X-Original-To: freebsd-stable@FreeBSD.ORG Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 22D7916A4DD for ; Mon, 28 Aug 2006 13:23:33 +0000 (UTC) (envelope-from michael@araneidae.co.uk) Received: from mail.araneidae.co.uk (araneidae.co.uk [62.3.233.233]) by mx1.FreeBSD.org (Postfix) with ESMTP id 75A2843D4C for ; Mon, 28 Aug 2006 13:23:32 +0000 (GMT) (envelope-from michael@araneidae.co.uk) Received: from saturn.araneidae.co.uk (localhost [127.0.0.1]) by mail.araneidae.co.uk (8.13.1/8.13.1) with ESMTP id k7SDNVhO062804; Mon, 28 Aug 2006 13:23:31 GMT (envelope-from michael@araneidae.co.uk) Received: from localhost (michael@localhost) by saturn.araneidae.co.uk (8.13.1/8.13.1/Submit) with ESMTP id k7SDNUL2062801; Mon, 28 Aug 2006 13:23:30 GMT (envelope-from michael@araneidae.co.uk) X-Authentication-Warning: saturn.araneidae.co.uk: michael owned process doing -bs Date: Mon, 28 Aug 2006 13:23:30 +0000 (GMT) From: Michael Abbott To: Oliver Fromme In-Reply-To: <200608281220.k7SCKoJW054182@lurza.secnetix.de> Message-ID: <20060828124935.G62656@saturn.araneidae.co.uk> References: <200608281220.k7SCKoJW054182@lurza.secnetix.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-stable@FreeBSD.ORG Subject: Re: NFS locking: lockf freezes (rpc.lockd problem?) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Aug 2006 13:23:33 -0000 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.