Deep Insights in Microsoft .NET

This is really a setting for a "quantum" a.k.a the amount of time a thread is permitted to run before it is pre-empted (not a problem for fibers). If you set it to programs/ applications it is a small value like 2 clock intervals. If you set it to background services, it is a large value like 12 clock intervals. The value for background services is larger and meant for server OS because throughput and performance are more important. Shorter quantums would mean more context switching and worse performance.

You would have seen this from SQL Server preferences. This could have come with the .NET framework at some point in time, but they kept it separate. http://stackoverflow.com/questions/796217/what-is-the-difference-between-a-thread-and-a-fiber This link is mostly correct. But not fully correct though. Windows NT will interrupt threads so that multiple threads can execute at the same time - true. But this will not cause any problems in normal course because if that was the case, half the programs in the world would not work properly. In reality, it is able to easily manage swapping one thread from kernel to user mode and vice versa along with loading all the data to and from the registers without losing information. In the C++ world, you have a lot of control and can change lots of stuff all over the place which can cause problems and data corruption.

http://blogs.msdn.com/b/phkelley/archive/2013/05/29/server-workspaces-vs-local-workspaces.aspx - Just use the classic server workspace which is much faster if your projects have greater than 100K items.

When the managed thread is aborted, an exception is introduced at the thread's current instruction pointer. This allows the finally blocks to execute as the thread winds down. The runtime is also aware of code that are performing non-interruptable operations like manipulating system state and so it will delay introducing the abort exception until a safe point has reached. Terminating a native thread does not free the user-mode stack. The thread can hold onto locks that after termination will remain in the acquired state. This thread could also have been modifying critical system state which gets corrupted when interrupted. If you terminate a native thread, you should probably be terminating the process as well.