10-16-2012, 01:30 AM
i have no idea how the windows kernel works with i/o scheduling, but it sounds like the process is i/o bound. if windows behaves anything like linux in this regard, the userspace signal handler will not run for that process while it is in IOWAIT.
basically, when a process is executing a system call like read() or write() which run in kernel mode, it marks itself as being in uninterruptible sleep as killing a kernel mode process could potentially corrupt the kernel structures used by all the other processes on the same system. when the kernel returns to user mode from kernel mode, it checks if there are any signals pending. this means a process can be killed only on return to user mode from kernel mode. it is very easy for long-running processes like this to get stuck in IOWAIT.
that's how most all unix-like operating systems behave anyway, i can't image windows would behave any differently.
there are things that can be done differently in mp to prevent this, such as making asynch writes to stdout, but it likely wouldn't be worth the effort involved.
basically, when a process is executing a system call like read() or write() which run in kernel mode, it marks itself as being in uninterruptible sleep as killing a kernel mode process could potentially corrupt the kernel structures used by all the other processes on the same system. when the kernel returns to user mode from kernel mode, it checks if there are any signals pending. this means a process can be killed only on return to user mode from kernel mode. it is very easy for long-running processes like this to get stuck in IOWAIT.
that's how most all unix-like operating systems behave anyway, i can't image windows would behave any differently.
there are things that can be done differently in mp to prevent this, such as making asynch writes to stdout, but it likely wouldn't be worth the effort involved.