Why can't terminate a process if its threads are in unkown states?

From my experience, when main thread is ready to exit, it should wait until other threads normally exit.

But from this link http://msdn.microsoft.com/en-us/library/ms686722(v=VS.85).aspx, it looks when process is terminated, all related resources are freed, so if certain worker thread is doing heavy work, waiting may be a litter longer. Can I ignore the waiting?

Also in the above link, I find

Do not terminate a process unless its threads are in known states. If a thread is waiting on a kernel object, it wi开发者_开发技巧ll not be terminated until the wait has completed. This can cause the application to hang.

This is too short to understand why killing a thread in unknown states when process exits is wrong.

can someone give me more detail about the problem?

Thanks

---

So, when a thread is waiting on an object in the kernel, it will not exit until the waiting is over.

So, let's say you have an application with 3 threads, in the following states:

1. Main thread, currently idle
2. UI handling thread, currently idle
3. A thread waiting on a kernel object

If you kill the process, thread 2 will die, making the UI input handlers die, and therefore giving the appearance that the application is unresponsive (hung). Until thread #3 finishes waiting on the kernel, the main thread won't exit, and so the process remains running, and the process resources don't get released.

So, I think it's basically saying that it's better to ask a process to exit normally, instead of sending it a kill signal, because you can get yourself into a situation like the one described if any of the process threads are waiting on kernel objects.