Re: NFS locking: lockf freezes (rpc.lockd problem?)

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.
_______________________________________________
freebsd-stable@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscribe@xxxxxxxxxxx"