All articles in Internet says that using Thread.Abort
is evil (because synchronization primitives belongs to operating system, and process doesn't terminate yet, and primitives might remain locked after thread aborting). Developers advises to terminate whole processes instead, because operation system will free synchronization primitives when process stops.
Will
AppDomain
unloading help, If one will useSlim
synchronization primitives? (With .net 4.0 several new classes have been added relating to threading:ManualResetEventSlim
,SemaphoreSlim
,ReaderWriterLockSlim
).Documentation says that these primitives can't be used beween different processes, because implementation code of primitives is fully managed. But I don't understand - will these primitives work through
AppDomain
border. (see Can't set synchronization context when using appdomains)If yes, how they do that? If no, then why documentation omit this limitation?
UPD: All my code is trusted by me, including the code inside the domain which i unload. I don't want to leave the thread working, when the time comes to terminate it. I want to terminate (abort) thread instead of "setting flag" and "making nice architecture". If it is neccessary to create additional thread first (i think this is necessary at start of background processing in separate domain to create one more thread), i will do. I don't want to use "setting flag" approach, because it requires me to instrument background algorithm with flag checks, i shouldn't, it's the runtime or compiler should automate that instrumentation for me. Right now there is no such instrumentation, that is why I am trying to apply the approach with domain unloading.
Adding checks between each instruction (or in deep nested cycles) will slow the code significantly. Adding check in random locations will not give guaranties of prompt termination. If difficulties of writing abort-safe code can be solved, why not to try to abort threads and unload domain?