Guenther Grau wrote:
> I think I know quite a bit about Unix-internals, but I was never
> really able to figure out why it is _neccessary_ to have a process
> in a state in which it cannot be delivered a SIGKILL. Can anybody
> clue me in on that one?
> I know that this usually happens when a process is waiting for
> 'fast' i/o, but why is it really needed, or this this just an
> optimization. IMHO, it should always be possible to remove
> a process from a system, regardless what the process is just
> doing.

As I understand it you can't kill a process if it's currently
executing a syscall. Maybe the syscall is in the middle of
updating something important, and if you killed it it might
leave kernel data structures corrupt. To be able to kill
a process at any point you'd need to make every syscall
be able to tidy-up from itself at any point during its
execution.

The above may be entirely wrong - I know nothing and
I'm guessing ;-).

I managed to get NetBSD 1.1 to deadlock the other day. I was
copying a file to disk, and tried to 'ls' the disk at the
same time (stupid me). Both processes got stuck in the 'D'
state and I had to reboot. Ho hum.

Oh yes, while I'm here - if I 'ping -f', my (EIDE) hard drive
locks up. (something about lost interrupts) Anybody know
why? (Intel Atlantis motherboard)

Cheers


Jon
____
\  //    Jon Ribbens    // 10MB virtual-hosted // www.oaktree.co.uk
 \// jon@oaktree.co.uk // web space for 49UKP //