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