 <p><code>Thread.Abort</code> will close the thread, of course, as it will call Win32 <a href="http://msdn.microsoft.com/en-us/library/ms686717(VS.85).aspx" rel="nofollow noreferrer"><code>TerminateThread</code></a>.</p> <p>Outcome of this action will depend on how your <code>API</code> likes to be closed by <code>TerminateThread</code>.</p> <p>If your method is called somthing like <code>NuclearPlant.MoveRod()</code> or <code>Defibrillator.Shock()</code>, I'd rather wait these 30 seconds.</p> <p>This method gives no chance to the victim to do some cleanup:</p> <blockquote> <p><code>TerminateThread</code> is used to cause a thread to exit. When this occurs, <em>the target thread has no chance to execute any user-mode code</em>. DLLs attached to the thread are not notified that the thread is terminating. The system frees the thread's initial stack.</p> </blockquote> <p>As stated in <code>MSDN</code>:</p> <blockquote> <p><code>TerminateThread</code> is a dangerous function that should only be used in the most extreme cases. You should call <code>TerminateThread</code> only if you know exactly what the target thread is doing, and you control all of the code that the target thread could possibly be running at the time of the termination. For example, <code>TerminateThread</code> can result in the following problems:</p> <ul> <li>If the target thread owns a critical section, the critical section will not be released.</li> <li>If the target thread is allocating memory from the heap, the heap lock will not be released.</li> <li>If the target thread is executing certain kernel32 calls when it is terminated, the kernel32 state for the thread's process could be inconsistent.</li> <li>If the target thread is manipulating the global state of a shared DLL, the state of the DLL could be destroyed, affecting other users of the DLL.</li> </ul> </blockquote>